Re: [HACKERS] Runtime Partition Pruning

Поиск
Список
Период
Сортировка
От Jesper Pedersen
Тема Re: [HACKERS] Runtime Partition Pruning
Дата
Msg-id 308e5f60-cf13-bf1e-73bc-4e40f5128baf@redhat.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Runtime Partition Pruning  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
Hi,

On 04/07/2018 04:45 AM, David Rowley wrote:
> Ok, so I've gone and done this.
> 
> PartitionPruning has become PartitionPruneState
> PartitionRelPruning has become PartitionPruningData
> 
> I've changed pointers to PartitionPruneStates to be named prunestate,
> sometimes having the node prefix; as_, ma_, in these cases prune and
> state are separated with a _ which seems to be the general rule for
> executor state struct members.
> 
> Generally, pointers to PartitionPruningData are now named pprune.
> Hopefully, that's ok, as this was the name previously used for
> PartitionPruning pointers.
> 
> I applied the patch to get rid of as_noop_scan in favour of using a
> special as_whichplan value. There was already one special value
> (INVALID_SUBPLAN_INDEX), so seemed better to build on that rather than
> inventing something new. This also means we don't have to make the
> AppendState struct and wider too, which seems like a good thing to try
> to do.
> 
> I made all the fixups which I mentioned in my review earlier and also
> re-removed the resultRelation parameter from make_partition_pruneinfo.
> It sneaked back into v22.
> 
> v23 is attached.
> 

Passes check-world.

Changing explain.c to "Subplans Removed" as suggested by you in [1] is a 
good idea.

[1] 
https://www.postgresql.org/message-id/CAKJS1f99JnkbOshdV_4zoJZ96DPtKeHMHv43JRL_ZdHRkkVKCA%40mail.gmail.com

Best regards,
  Jesper


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

Предыдущее
От: Teodor Sigaev
Дата:
Сообщение: Re: WIP: Covering + unique indexes.
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: [HACKERS] [PATCH] Incremental sort