Re: numbering plan nodes

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: numbering plan nodes
Date: 2015-09-17 23:20:23
Message-ID: CA+TgmobbO3gJ-uov2C=r7BhcXiuRNWb67m_gqG-ZLU1JTvmG+A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 17, 2015 at 4:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Sep 17, 2015 at 2:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I can't imagine I'd be doing anything that would break the simple case
>>> of "give every node a distinct ID". If you are building in weird
>>> assumptions about traversal order, that might indeed be a problem.
>
>> Good to know, thanks. With the design you proposal above, we can make
>> this insensitive to traversal order. The only thing that would cause
>> trouble is if you somehow ended up with massive gaps in the numbering
>> sequence - e.g. if the final plan had 6 nodes, but the IDs were all 5
>> digit numbers, you'd waste a silly amount of memory relative to the
>> size of the plan. But a few gaps (e.g. for removed SubqueryScan
>> nodes) won't be a problem.
>
> Hm ... if you quit worrying about the order-of-assignment, maybe you
> could prevent gaps from removed SubqueryScan nodes by not giving them
> IDs until after that decision is made?

Hmm, that might work. I'll try it.

> Although it may not be worth
> any extra trouble.

Right. If it doesn't turn out to be easy, I won't worry about it.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-09-17 23:29:30 Re: numbering plan nodes
Previous Message Andrew Dunstan 2015-09-17 23:09:04 Re: cache type info in json_agg and friends