Re: [HACKERS] Runtime Partition Pruning
От | Beena Emerson |
---|---|
Тема | Re: [HACKERS] Runtime Partition Pruning |
Дата | |
Msg-id | CAOG9ApHyt1162NJmtbp26RFY0Nkx+HK5CyV9DOQaJSrBm=rQKQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Runtime Partition Pruning (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Runtime Partition Pruning
|
Список | pgsql-hackers |
Hello, On Mon, Dec 18, 2017 at 4:03 PM, David Rowley <david.rowley@2ndquadrant.com> wrote: > >> We could do something similar here using a similar code structure. Maybe, >> add a ExecSetupPartitionRuntimePruning() in execPartition.c (mimicking >> ExecSetupPartitionTupleRouting), that accepts AppendState node. >> Furthermore, it might be a good idea to have something similar to >> ExecFindPartition(), say, ExecGetPartitions(). That is, we have new >> functions for run-time pruning that are counterparts to corresponding >> functions for tuple routing. > > Seems to me in this case we're better to build this structure during > planning and save it with the plan so that it can be used over and > over, rather than building it again and again each time the plan is > executed. Likely a common use case for run-time pruning is when the > plan is going to be used multiple times with different parameters, so > we really don't want to repeat any work that we don't have to here. > I agree. It would be better to avoid building the structure during execution. PFA the updated patch. -- Beena Emerson EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: