Re: [HACKERS] path toward faster partition pruning

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: [HACKERS] path toward faster partition pruning
Дата
Msg-id CAKJS1f-Ob0bR2bZi4752kt7p8PkRTZxHfyvJFdw4GsMvZvNY_Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] path toward faster partition pruning  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] path toward faster partition pruning  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 7 April 2018 at 15:41, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> David Rowley <david.rowley@2ndquadrant.com> writes:
>> Sounds like you're saying that if we have too many alternative files
>> then there's a chance that one could pass by luck.
>
> Yeah, exactly: it passed, but did it pass for the right reason?
>
> If there's just two expected-files, it's likely not a big problem,
> but if you have a bunch it's something to worry about.

Right, I suggest we wait and see if all members go green again as a
result of 40e42e1024c, and if they're happy then we could maybe leave
it as is with the 2 alternatives output files.

If there are some other variations that crop up, then we can think
harder about what we can do to improve the coverage.

I don't particularly think it matters which hash partition a tuple
goes into, as long as the hash function spreads the values out enough
and most importantly, the pruning code looks for the tuple in the
partition that it was actually inserted into in the first place.
Obviously, we also want to ensure we never do anything which would
change the matching partition in either minor or major version
upgrades too.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] path toward faster partition pruning
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] path toward faster partition pruning