Re: Common Table Expressions (WITH RECURSIVE) patch

From: "Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Greg Stark" <stark(at)enterprisedb(dot)com>, "Dimitri Fontaine" <dfontaine(at)hi-media(dot)com>, "Jeff Davis" <pgsql(at)j-davis(dot)com>, "Tatsuo Ishii" <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Common Table Expressions (WITH RECURSIVE) patch
Date: 2008-10-01 16:05:57
Message-ID: e08cc0400810010905t6605bc22ldaf6c894b6d8b774@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> One other reason the tuplestore should know the position of all the
>> readers is that ideally it would want to be able to discard any tuples
>> older than the oldest read position. That also means it needs to know
>> when all the call sites have allocated their position and don't need
>> to reset it.
>
> Good point. So we'd need per-position capability flags, not
> per-tuplestore.
>
> I hadn't realized that this would be relevant to window functions.
> Now that I know that, I propose fixing tuplestore for multiple
> positions and committing it separately, before I go back to the CTE
> patch. Then Hitoshi-san will have something he can work with too.
>

Yes, tuplestore multiple positioning will give the greate help to the
window function. Ideally, it is better that tuplestore'd have all the
positions and have some kind of capability to discard old rows so that
it can stay in TSS_MEM, which helps window function's sliding frame.
But it isn't really critical, just performance matter.

Regards,

--
Hitoshi Harada

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Csaba Nagy 2008-10-01 16:07:05 Re: Block-level CRC checks
Previous Message Tom Lane 2008-10-01 16:05:06 Re: Block-level CRC checks