Re: generic plans and "initial" pruning
От | Amit Langote |
---|---|
Тема | Re: generic plans and "initial" pruning |
Дата | |
Msg-id | CA+HiwqGzJujaEJe_Tx8gXcrJGbJ_aZoCOk_jS=vMknfbpxvNKw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: generic plans and "initial" pruning (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: generic plans and "initial" pruning
|
Список | pgsql-hackers |
On Wed, Oct 12, 2022 at 4:36 PM Amit Langote <amitlangote09@gmail.com> wrote: > On Fri, Jul 29, 2022 at 1:20 PM Amit Langote <amitlangote09@gmail.com> wrote: > > On Thu, Jul 28, 2022 at 1:27 AM Robert Haas <robertmhaas@gmail.com> wrote: > > > 0001 adds es_part_prune_result but does not use it, so maybe the > > > introduction of that field should be deferred until it's needed for > > > something. > > > > Oops, looks like a mistake when breaking the patch. Will move that bit to 0002. > > Fixed that and also noticed that I had defined PartitionPruneResult in > the wrong header (execnodes.h). That led to PartitionPruneResult > nodes not being able to be written and read, because > src/backend/nodes/gen_node_support.pl doesn't create _out* and _read* > routines for the nodes defined in execnodes.h. I moved its definition > to plannodes.h, even though it is not actually the planner that > instantiates those; no other include/nodes header sounds better. > > One more thing I realized is that Bitmapsets added to the List > PartitionPruneResult.valid_subplan_offs_list are not actually > read/write-able. That's a problem that I also faced in [1], so I > proposed a patch there to make Bitmapset a read/write-able Node and > mark (only) the Bitmapsets that are added into read/write-able node > trees with the corresponding NodeTag. I'm including that patch here > as well (0002) for the main patch to work (pass > -DWRITE_READ_PARSE_PLAN_TREES build tests), though it might make sense > to discuss it in its own thread? Had second thoughts on the use of List of Bitmapsets for this, such that the make-Bitmapset-Nodes patch is no longer needed. I had defined PartitionPruneResult such that it stood for the results of pruning for all PartitionPruneInfos contained in PlannedStmt.partPruneInfos (covering all Append/MergeAppend nodes that can use partition pruning in a given plan). So, it had a List of Bitmapset. I think it's perhaps better for PartitionPruneResult to cover only one PartitionPruneInfo and thus need only a Bitmapset and not a List thereof, which I have implemented in the attached updated patch 0002. So, instead of needing to pass around a PartitionPruneResult with each PlannedStmt, this now passes a List of PartitionPruneResult with an entry for each in PlannedStmt.partPruneInfos. -- Thanks, Amit Langote EDB: http://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: