Re: numbering plan nodes

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: numbering plan nodes
Date: 2015-09-18 03:05:05
Message-ID: CA+TgmoZawBT2rcKhmZZEWZJ9QkGog0s66NrxaKuqyMYz7O9eEw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 17, 2015 at 9:01 PM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> I entirely agree with the idea of plan-node identifier, however,
> uncertain whether the node-id shall represent physical location on
> the dynamic shared memory segment, because
> (1) Relatively smaller number of node type needs shared state,
> thus most of array items are empty.
> (2) Extension that tries to modify plan-tree using planner_hook
> may need to adjust node-id also.
>
> Even though shm_toc_lookup() has to walk on the toc entries to find
> out the node-id, it happens at once on beginning of the executor at
> background worker side. I don't think it makes a significant problem.

Yes, I was thinking that what would make sense is to have each
parallel-aware node call shm_toc_insert() using its ID as the key.
Then, we also need Instrumentation nodes. For those, I thought we
could use some fixed, high-numbered key, and Tom's idea.

Are there extensions that use planner_hook to do surgery on the plan
tree? What do they do, exactly?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2015-09-18 03:44:13 Re: Parallel Seq Scan
Previous Message Euler Taveira 2015-09-18 03:00:36 vacuumdb sentence