Re: Sudden database error with COUNT(*) making Query Planner crashes: variable not found in subplan target list
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Sudden database error with COUNT(*) making Query Planner crashes: variable not found in subplan target list |
| Дата | |
| Msg-id | 1312554.1654631755@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Sudden database error with COUNT(*) making Query Planner crashes: variable not found in subplan target list (David Rowley <dgrowleyml@gmail.com>) |
| Ответы |
Re: Sudden database error with COUNT(*) making Query Planner crashes: variable not found in subplan target list
|
| Список | pgsql-hackers |
David Rowley <dgrowleyml@gmail.com> writes:
> On Tue, 7 Jun 2022 at 19:58, Jean Landercy - BEEODIVERSITY
> <jean.landercy@beeodiversity.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
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера