Re: Slow plan choice with prepared query

2022-02-24 Thread MichaelDBA
As per PG official documentation on PREPARE, it is working as expected.  Use custom plan, but after 5th iteration compare cost of custom plan vs generic plan and use the one with the less cost which is the generic plan even though it is not as performant. Look at explain output to see the diffs

Re: Slow plan choice with prepared query

2022-02-24 Thread MichaelDBA
Dag, if you ain't right!  I can duplicate this on the ones I tested with: PG v11 and v14.  Gonna start diving into this myself... Regards, Michael Vitale Mark Saward wrote on 2/23/2022 10:37 PM: Hi, I've experienced a situation where the planner seems to make a very poor choice with a prep

Re: Advice needed: query performance deteriorates by 2000% within 1 minute

2022-02-24 Thread Tom Lane
Peter Adlersburg writes: > Limit (cost=0.00..804.97 rows=10 width=22) (actual > time=23970.845..25588.432 rows=1 loops=1) >-> Seq Scan on "order" (cost=0.00..3863.86 rows=48 width=22) (actual > time=23970.843..25588.429 rows=1 loops=1) > Filter: (jsonb_to_tsvector('english'::regco

Re: Advice needed: query performance deteriorates by 2000% within 1 minute

2022-02-24 Thread Michael Lewis
You are getting row estimate 48 in both cases, so it seems perhaps tied to the free space map that will mean more heap lookups from the index, to the point where the planner thinks that doing sequential scan is less costly. What is random_page_cost set to? Do you have default autovacuum/analyze se

Advice needed: query performance deteriorates by 2000% within 1 minute

2022-02-24 Thread Peter Adlersburg
Dear fellow DBAs, I am seeking for some guidance with the following case that our developers have thrown at me and I apologize in advance for this lengthy mail ... $> postgres --version postgres (PostgreSQL) 13.6 We are dealing with the following issue: select version, content from orderstore

Re: An I/O error occurred while sending to the backend (PG 13.4)

2022-02-24 Thread Ranier Vilela
Em qui., 24 de fev. de 2022 às 09:59, Justin Pryzby escreveu: > On Thu, Feb 24, 2022 at 08:50:45AM -0300, Ranier Vilela wrote: > > I can't understand why you are still using 13.4? > > [1] There is a long discussion about the issue with 13.4, the project was > > made to fix a DLL bottleneck. > > >

Re: An I/O error occurred while sending to the backend (PG 13.4)

2022-02-24 Thread Justin Pryzby
On Thu, Feb 24, 2022 at 08:50:45AM -0300, Ranier Vilela wrote: > I can't understand why you are still using 13.4? > [1] There is a long discussion about the issue with 13.4, the project was > made to fix a DLL bottleneck. > > Why you not use 13.6? That other problem (and its fix) were in the wind

Re: An I/O error occurred while sending to the backend (PG 13.4)

2022-02-24 Thread Ranier Vilela
Em qua., 23 de fev. de 2022 às 21:47, l...@laurent-hasson.com < l...@laurent-hasson.com> escreveu: > > >> -Original Message- >> From: l...@laurent-hasson.com >> Sent: Saturday, December 4, 2021 14:18 >> To: Justin Pryzby >> Cc: pgsql-performa...@postgresql.org >