Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Tue, 26 Mar 2019 at 09:00, Tom Lane wrote: > > David Rowley writes: > > [ drop-useless-merge-appends-15.patch ] > > Pushed with some minor adjustments. Thank for all your work on this, and thanks for the final push. FWIW, you should probably have credited yourself as the main author since I

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

David Rowley writes: > [ drop-useless-merge-appends-15.patch ] Pushed with some minor adjustments. > I can get a plan that does end up with Result nodes above a Scan node. > create table rangep (a int, b int) partition by range (a); > create table rangep1 partition of rangep for values from(0)

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Mon, 4 Mar 2019 at 16:26, Tom Lane wrote: > I was a bit surprised to find that I didn't need to fool around > with lying about whether [Merge]Append can project. I've not dug > into the exact reason why, but I suspect it's that previous changes > made in support of parallelization have

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

David Rowley writes: > On Mon, 4 Mar 2019 at 16:26, Tom Lane wrote: >> One other remark is that the division of labor between >> create_[merge]append_path and their costsize.c subroutines >> seems pretty unprincipled. I'd be inclined to push all the >> relevant logic into costsize.c, but have

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Mon, 4 Mar 2019 at 16:26, Tom Lane wrote: > > David Rowley writes: > > [ v13-0001-Forgo-generating-single-subpath-Append-and-Merge.patch ] > > I continue to think that this is the wrong way to go about it, > and as proof of concept present the attached, which reproduces > all of the

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

David Rowley writes: > [ v13-0001-Forgo-generating-single-subpath-Append-and-Merge.patch ] I continue to think that this is the wrong way to go about it, and as proof of concept present the attached, which reproduces all of the regression-test plan changes appearing in v13 --- with a whole lot

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Thu, 31 Jan 2019 at 17:22, David Rowley wrote: > I've also attached a rebased patch. Rebased again. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services v12-0001-Forgo-generating-single-subpath-Append-and-Merge.patch

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Sat, 26 Jan 2019 at 13:51, Tom Lane wrote: > > David Rowley writes: > > On Thu, 3 Jan 2019 at 08:01, Tomas Vondra > > wrote: > >> AFAICS the patch essentially does two things: (a) identifies Append > >> paths with a single member and (b) ensures the Vars are properly mapped > >> when the

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

David Rowley writes: > On Thu, 3 Jan 2019 at 08:01, Tomas Vondra > wrote: >> AFAICS the patch essentially does two things: (a) identifies Append >> paths with a single member and (b) ensures the Vars are properly mapped >> when the Append node is skipped when creating the plan. >> I agree doing

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

I've attached an updated patch. The last one no longer applied due to the changes made in d723f5687 -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services v10-0001-Forgo-generating-single-subpath-Append-and-Merge.patch

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Thu, 3 Jan 2019 at 08:01, Tomas Vondra wrote: > AFAICS the patch essentially does two things: (a) identifies Append > paths with a single member and (b) ensures the Vars are properly mapped > when the Append node is skipped when creating the plan. Yes, but traditional Append and MergeAppend

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On 4/1/18 9:26 AM, David Rowley wrote: > On 16 March 2018 at 04:01, Tom Lane wrote: >> I hadn't been paying much attention to this thread, but I've now taken >> a quick look at the 2018-02-19 patch, and I've got to say I do not like >> it much. The changes in createplan.c in particular seem like

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Mon, 2 Jul 2018 at 09:37, David Rowley wrote: > Now that the September 'fest is open for new patches I'm going to move > this patch over there. This patch has become slightly less important > than some other stuff, but I'd still like to come back to it. This had bit-rotted quite a bit, so

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Mon, Jul 02, 2018 at 09:37:31AM +1200, David Rowley wrote: > Now that the September 'fest is open for new patches I'm going to move > this patch over there. This patch has become slightly less important > than some other stuff, but I'd still like to come back to it. Please note that the

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

Now that the September 'fest is open for new patches I'm going to move this patch over there. This patch has become slightly less important than some other stuff, but I'd still like to come back to it. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On 16 March 2018 at 04:01, Tom Lane wrote: > I hadn't been paying much attention to this thread, but I've now taken > a quick look at the 2018-02-19 patch, and I've got to say I do not like > it much. The changes in createplan.c in particular seem like hack-and- > slash

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On 16 March 2018 at 02:46, Robert Haas 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

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

Robert Haas writes: > On Thu, Mar 15, 2018 at 11:01 AM, Tom Lane wrote: >> It might be worth looking at whether we couldn't fix the single-member- >> Append issue the same way we fix no-op SubqueryScans, ie let setrefs.c >> get rid of them. That's not

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Thu, Mar 15, 2018 at 11:01 AM, Tom Lane wrote: > It might be worth looking at whether we couldn't fix the single-member- > Append issue the same way we fix no-op SubqueryScans, ie let setrefs.c > get rid of them. That's not the most beautiful solution perhaps, but > it'd

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

Robert Haas writes: > That said, I gather that one problem is the path might contain > references to child varnos where we need to reference parent varnos. > That does seem like something we need to handle, but I'm not sure > whether this is really the right method. I

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Thu, Mar 15, 2018 at 9:22 AM, Robert Haas wrote: >> Wouldn't a ProjectionPath just need the same additional translation >> fields that I've bolted onto AppendPath to make it work properly? > > Well, I guess I'm not sure. Sorry, hit send too soon there. I'm not sure I

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Tue, Mar 13, 2018 at 8:20 PM, David Rowley wrote: > On 14 March 2018 at 09:25, Robert Haas wrote: >> What do you think about the idea of using a projection path as a proxy >> path instead of inventing a new method? It seems simple enough

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On 14 March 2018 at 09:25, Robert Haas wrote: > What do you think about the idea of using a projection path as a proxy > path instead of inventing a new method? It seems simple enough to do: > > new_path = (Path *) create_projection_path(root, new_rel, old_path, >

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Mon, Feb 19, 2018 at 4:02 AM, David Rowley wrote: > On 19 February 2018 at 18:01, David Rowley > wrote: >> On 19 February 2018 at 15:11, Tomas Vondra >> wrote: >>> and perhaps we should do

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On 19 February 2018 at 18:01, David Rowley wrote: > On 19 February 2018 at 15:11, Tomas Vondra > wrote: >> and perhaps we should do s/isproxy/is_proxy/ which seems like the usual >> naming for boolean variables. > > You're right. I'll

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On 19 February 2018 at 15:11, Tomas Vondra wrote: > 1) I can confirm that it indeed eliminates the Append overhead, using > the example from [1], modified to use table with a single partition. Of > course, this is a pretty formal check, because the patch simply

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

Hi, On 01/25/2018 01:55 PM, David Rowley wrote: > I've attached an updated patch which takes care of the build failure > caused by the new call to create_append_path added in bb94ce4. > I've been looking at the patch over the past few days. I haven't found any obvious issues with it, but I do

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

I've attached an updated patch which takes care of the build failure caused by the new call to create_append_path added in bb94ce4. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

I've attached a rebased patch. The previous patch was conflicting with parallel Hash Join (180428404) -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services remove_singleton_appends_2017-12-28.patch Description: Binary data

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Mon, Dec 11, 2017 at 3:16 PM, David Rowley wrote: > > Sometime in the future, I'd like to see some sort of UniqueKeys List > in RelOptInfo which is initially populated by using looking at the > unique indexes during build_simple_rel(). The idea is that these >

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On 11 December 2017 at 22:23, Ashutosh Bapat wrote: > I think this didn't work with inheritance before partition-wise join > as well for the same reason. Yeah, I was just demonstrating a reason that the plans are not identical from querying a partitioned table

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Mon, Dec 11, 2017 at 2:42 PM, David Rowley wrote: > On 11 December 2017 at 21:18, Ashutosh Bapat > wrote: >> On Thu, Dec 7, 2017 at 5:11 AM, David Rowley >> wrote: >>> While rebasing this today I

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On 11 December 2017 at 21:18, Ashutosh Bapat wrote: > On Thu, Dec 7, 2017 at 5:11 AM, David Rowley > wrote: >> While rebasing this today I also noticed that we won't properly detect >> unique joins in add_paths_to_joinrel() as we're

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Thu, Dec 7, 2017 at 5:11 AM, David Rowley wrote: > > While rebasing this today I also noticed that we won't properly detect > unique joins in add_paths_to_joinrel() as we're still testing for > uniqueness against the partitioned parent rather than the only child.

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On 30 November 2017 at 15:34, Michael Paquier wrote: > On Wed, Nov 15, 2017 at 3:17 PM, David Rowley > wrote: > > The remove_singleton_appends_examples_of_differences_2017-11-15.patch > > which I've attached applies changes to the