Re: single table - fighting a seq scan

Поиск
Список
Период
Сортировка
От Radoslav Nedyalkov
Тема Re: single table - fighting a seq scan
Дата
Msg-id CANhtRiY_Lr1w_-qkLhWwDHMkdbx6iE3W9eQ-iJLYSxiCQhWmJg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: single table - fighting a seq scan  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: single table - fighting a seq scan  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
Shame on me. It's a partial index - where is not null.
Put the is not null predicate in place and planner always goes for index. (tested with thousands of IN entries)
CTE version always goes for index too even without is not null , which led to a slight confusion.

Thanks Tom, Michael,
Best
Rado

On Wed, Jul 15, 2020 at 1:06 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Radoslav Nedyalkov <rnedyalkov@gmail.com> writes:
> Ah, I could have messed up the examples I gave. Row numbers are different.
> Once again the plans , sorry about that.

Given that it works at 100 entries and not 101, I can't escape the
suspicion that you're being burnt by predtest.c's MAX_SAOP_ARRAY_SIZE
limit.  However, that only affects the planner's willingness to make
constraint proofs involving the large IN clause, and nothing you've
mentioned here explains why such a proof would be needed.  Is there
something you're not telling us about this table's schema?  (I'm
wondering if the index is partial, for instance, though one would
think that the CTE form of the query wouldn't work either if so.)

                        regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: "Daniel Verite"
Дата:
Сообщение: RE: psql: FATAL: database "postgres" does not exist or ERROR: 23505: duplicate key value violates unique constraint "pg_namespace_nspname_index"
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: Cross-site cookies warnings