| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| 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 01:54:46 |
| Message-ID: | CAApHDvpYPKZxf=zqtjKhR9W8yKn0R2ojyoMkC=zcmVv9M4FSyQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On Thu, 7 Jul 2022 at 12:46, Andres Freund <andres(at)anarazel(dot)de> wrote:
> 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 forgot to mention what the "generic problem" is when I posted my
reply. I should have mentioned that this is how we cost LIMIT. We
assume that we'll find the LIMIT 1 row after incurring the scan cost
multiplied by (1 / 259201).
For the plan with WHERE timestamp >= $1, the seqscan plan looks pretty
cheap for fetching DEFAULT_INEQ_SEL of the 259201 rows considering the
LIMIT multiples the cost of the scan by (1 / 86400).
David
| From | Date | Subject | |
|---|---|---|---|
| Next 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 |
| Previous Message | Andres Freund | 2022-07-07 00:46:46 | Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2022-07-07 02:13:54 | Re: tuplesort Generation memory contexts don't play nicely with index builds |
| Previous Message | Masahiko Sawada | 2022-07-07 01:50:39 | Re: Issue with pg_stat_subscription_stats |