From: | "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Example code Re: Singleton SELECT inside cursor loop |
Date: | 2022-10-01 12:20:00 |
Message-ID: | 20221001122000.jq7f5wnmzbewimpn@hjp.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2022-10-01 02:22:22 -0500, Ron wrote:
> I extracted the singleton into a function, and that helped me isolate the
> problem.
I don't know what a singleton select is (duckduckgo tells me it has
something to do with DB2 and/or COBOL, or maybe it's a whisky), but:
> Note how quickly it runs the first five times, but takes 780x longer the
> sixth time I run it. Exiting psql and entering again causes the same
> slowness the sixth time it's run.
PostgresSQL evaluates the exact plan the first 5 times it encounters the
same prepared query. After that it switches to a generic plan if it
thinks that the generic plan isn't worse than the specialized plans.
If the plan suddenly gets worse after 5 executions, you've probably run
into a case where the generic plan is worse although the cost computed
by the planner isn't.
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp(at)hjp(dot)at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Moench-Tegeder | 2022-10-01 12:21:15 | Re: Example code Re: Singleton SELECT inside cursor loop |
Previous Message | Peter J. Holzer | 2022-10-01 12:05:53 | Names of run-time configuration parameters (was: Limiting the operations that client-side code can perform upon its database backend's artifacts) |