Re: Example code Re: Singleton SELECT inside cursor loop

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!"

In response to

Responses

Browse pgsql-general by date

  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)