| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Jean Landercy - BEEODIVERSITY <jean(dot)landercy(at)beeodiversity(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Sudden database error with COUNT(*) making Query Planner crashes: variable not found in subplan target list |
| Date: | 2022-06-07 19:55:55 |
| Message-ID: | 1312554.1654631755@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Tue, 7 Jun 2022 at 19:58, Jean Landercy - BEEODIVERSITY
> <jean(dot)landercy(at)beeodiversity(dot)com> wrote:
>> Here is the detail of the table (I have anonymized it on SO, this is its real name):
>> "logistic_site_location_54ae0166_id" gist (location)
> I imagine this is due to the planner choosing an index-only scan on
> the above index. A similar problem was reported in [1].
The other gist index could also be the problem. It seems odd though
that the planner would favor either index for this purpose over the btree
indexes on scalar columns, which you'd think would be a lot smaller.
I wonder if there is some quirk in gist cost estimation that makes it
improperly claim to be cheaper than btree scans.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-06-07 20:10:34 | Re: Collation version tracking for macOS |
| Previous Message | Peter Geoghegan | 2022-06-07 19:53:08 | Re: Collation version tracking for macOS |