Re: unsupportable composite type partition keys

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: unsupportable composite type partition keys
Дата
Msg-id 20151.1577127467@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: unsupportable composite type partition keys  (Amit Langote <amitlangote09@gmail.com>)
Ответы Re: unsupportable composite type partition keys  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Amit Langote <amitlangote09@gmail.com> writes:
> On Mon, Dec 23, 2019 at 23:49 Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Oh, interesting --- I hadn't been paying much attention to that thread.
>> I'll compare your PoC there to what I did.

> Actually, I should’ve said that your patch is much better attempt at
> getting this in order, so there’s not much to see in my patch really. :)

One thing I see is that you chose to relocate RelationGetPartitionDesc's
declaration to partdesc.h, whereupon RelationBuildPartitionDesc doesn't
have to be exported at all anymore.  Perhaps that's a better factorization
than what I did.  It supposes that any caller of RelationGetPartitionDesc
is going to need partdesc.h, but that seems reasonable.  We could likewise
move RelationGetPartitionKey to partcache.h.

            regards, tom lane



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

Предыдущее
От: Mahendra Singh
Дата:
Сообщение: Re: [HACKERS] Block level parallel vacuum
Следующее
От: Mahendra Singh
Дата:
Сообщение: relpages of btree indexes are not truncating even after deleting allthe tuples from table and doing vacuum