| From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath |
| Date: | 2018-04-01 06:17:09 |
| Message-ID: | CAKJS1f-BfywEPWtg2DmL67-zsecH5TNoRtCY9B_dw1iPa5W8vQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 16 March 2018 at 02:46, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> If we stick with your idea of using AppendPath, do we actually need
> generate_proxy_paths()? What paths get lost if we don't have a
> special case for them here?
Actually, we do a surprisingly good job of allowing plan shapes to
stay the same when planning for an only-child scan for an Append or
MergeAppend. The main difference I did find was that and Append and
MergeAppend don't support Mark and Restore, so if you just generated
the same paths and simply skipped over Appends and MergeAppends you'd
still be left with Materialize nodes which might not actually be
required at all.
This might not be huge, but seeing this made me worried that there
might be some valid reason, if not today, then sometime in the future
why it might not be safe to simply pluck the singleton
Append/MergeAppend nodes out the plan tree.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fabien COELHO | 2018-04-01 06:30:17 | Re: csv format for psql |
| Previous Message | Tom Lane | 2018-04-01 05:30:07 | Re: [HACKERS][PATCH] adding simple sock check for windows |