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
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 |