| 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: | Whole Thread | Raw Message | 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) |