Re: [HACKERS] Gather Merge - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Gather Merge
Date
Msg-id CA+Tgmobk69cto4nSCpcG+O5D5CtCVsLC8sXNsvx+Om=mn_O88w@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Gather Merge  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [HACKERS] Gather Merge  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Sat, Feb 18, 2017 at 6:43 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> I think there is a value in supporting mark/restore position for any
> node which produces sorted results, however, if you don't want to
> support it, then I think we should update above comment in the code to
> note this fact.  Also, you might want to check other places to see if
> any similar comment updates are required in case you don't want to
> support mark/restore position for GatherMerge.

I don't think it makes sense to put mark/support restore into Gather
Merge.  Maybe somebody else will come up with a test that shows
differently, but ISTM that with something like Sort it makes a ton of
sense to support mark/restore because the Sort node itself can do it
much more cheaply than would be possible with a separate Materialize
node.  If you added a separate Materialize node, the Sort node would
be trying to throw away the exact same data that the Materialize node
was trying to accumulate, which is silly.  Here with Gather Merge
there is no such thing happening; mark/restore support would require
totally new code - probably we would end up shoving the same code that
already exists in Materialize into Gather Merge as well.  That doesn't
seem like a good idea off-hand.

A comment update is probably a good idea, though.

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Instability in select_parallel regression test
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Suppressing that pesky warning with older flex versions