Re: Mark/Restore and avoiding RandomAccess sorts

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Mark/Restore and avoiding RandomAccess sorts
Дата
Msg-id 1168443369.3951.380.camel@silverbirch.site
обсуждение исходный текст
Ответ на Re: Mark/Restore and avoiding RandomAccess sorts  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Mark/Restore and avoiding RandomAccess sorts  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, 2007-01-10 at 10:10 -0500, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > Merge Joins require us to potentially Mark and Restore positions in the
> > tuples arriving from executor sub-nodes.
> 
> I came across an old note to myself suggesting that we handle this by
> interposing a Materialize node, and then teaching Material that if it's
> told EXEC_FLAG_MARK but not EXEC_FLAG_REWIND or EXEC_FLAG_BACKWARD, it
> need keep data only as far back as the Mark position.  So the structural
> requirements are mostly in place already, it's just a matter of figuring
> out a nice way to implement the "drop older parts of the tuplestore"
> business.

Same idea, I guess.

Presumably we'd need to teach the Materialize node to pass straight
through when the node does not receive any of EXEC_FLAG_MARK,
EXEC_FLAG_REWIND or EXEC_FLAG_BACKWARD.

The Materialize node would have to communicate with the Sort node so it
could indicate when it had passed its max size limit, so the Sort could
complete the final merge in-situ without wasting more space. Would it be
ugly to have the Materialize poke into the SortState?

Anyway, not just yet.

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Zdenek Kotala
Дата:
Сообщение: Re: ECPG regression test failures on Solaris 10/x86_64 with
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCHES] COPY with no WAL, in certain circumstances