From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, william(dot)duclot(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower |
Date: | 2022-07-07 03:13:18 |
Message-ID: | 2733255.1657163598@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> I think the cost for the slow plan being so much cheaper can almost be
> qualified as bug.
> The slow plan seems pretty nonsensical to me. ISTM that something in the
> costing there is at least almost broken.
I think this is probably an instance of the known problem that a generic
plan is made without knowledge of the actual parameter values, and that
can lead us to make statistical assumptions that are not valid for the
actual values, but nonetheless make one plan look cheaper than another
even though the opposite is true given the actual values. In essence,
comparing the cost estimate for the generic plan to the cost estimate
for a custom plan is not really logically valid, because those estimates
are founded on different statistics. I don't know how to fix that :-(.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2022-07-07 03:31:30 | Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower |
Previous Message | Tom Lane | 2022-07-07 03:06:59 | Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower |
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Barwick | 2022-07-07 03:14:44 | Re: Fast COPY FROM based on batch insert |
Previous Message | Tom Lane | 2022-07-07 03:06:59 | Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower |