Re: [HACKERS] path toward faster partition pruning

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] path toward faster partition pruning
Дата
Msg-id CA+TgmoZ00jf4Mo5WizPWzU4DKBK8bV03idxYvVZpHyKJsTxG9Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] path toward faster partition pruning  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: [HACKERS] path toward faster partition pruning
Список pgsql-hackers
On Tue, Feb 27, 2018 at 8:12 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> Ah, OK. I was missing that there is no need to have both parttypcoll and
> partcollation in PartitionSchemeData, as the Vars in rel->partexprs are
> built from a bare PartitionKey (not PartitionSchemeData), and after that
> point, parttypcoll no longer needs to kept around.
>
> I noticed that there is a typo in the patch.
>
> +       memcpy(part_scheme->partcollation, partkey->parttypcoll,
>
> s/parttypcoll/partcollation/g

Committed your version.

> BTW, should there be a relevant test in partition_join.sql?  If yes,
> attached a patch (partitionwise-join-collation-test-1.patch) to add one.

I don't feel strongly about it, but I'm not going to try to prevent
you from adding one, either.

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


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

Предыдущее
От: Shubham Barai
Дата:
Сообщение: Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Следующее
От: Grigory Smolkin
Дата:
Сообщение: Re: Changing the autovacuum launcher scheduling; oldest table firstalgorithm