Re: [HACKERS] path toward faster partition pruning

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] path toward faster partition pruning
Дата
Msg-id CA+TgmoYsw3pusDen4_A44c7od+bEAST0eYo+jODtyofR0W2soQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] path toward faster partition pruning  (Jesper Pedersen <jesper.pedersen@redhat.com>)
Ответы Re: [HACKERS] path toward faster partition pruning  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On Tue, Sep 26, 2017 at 10:57 AM, Jesper Pedersen
<jesper.pedersen@redhat.com> wrote:
> One could advocate (*cough*) that the hash partition patch [1] should be
> merged first in order to find other instances of where other CommitFest
> entries doesn't account for hash partitions at the moment in their method
> signatures; Beena noted something similar in [2]. I know that you said
> otherwise [3], but this is CommitFest 1, so there is time for a revert
> later, and hash partitions are already useful in internal testing.

Well, that's a fair point.  I was assuming that committing things in
that order would cause me to win the "least popular committer" award
at least for that day, but maybe not.  It's certainly not ideal to
have to juggle that patch along and keep rebasing it over other
changes when it's basically done, and just waiting on other
improvements to land.  Anybody else wish to express an opinion?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

Предыдущее
От: Alvaro Hernandez
Дата:
Сообщение: Re: [HACKERS] Built-in plugin for logical decoding output
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?