From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sample of user-define window function and other things |
Date: | 2009-01-08 14:05:29 |
Message-ID: | 14815.1231423529@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com> writes:
> 2009/1/8 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> You mean set_mark? It's just to save an extra calculation of the
>> absolute location of the fetched row. See leadlag_common for an
>> example use: we can truncate the tuplestore if the offset is constant.
> Yeah, I mean set_mark :P) I already checked leadlag_common example but
> abs_pos can be very simply calculated by WinGetCurrentPosition() -
> offset. So the simpler API is winner to me rather than saving few
> cycle cpu cost.
In this particular case it's not hard, but in the general case where you
are using any of the seekpos values it could require a significant
amount of code. More to the point: the available examples suggest
to me that truncating at the row you fetch is likely to be a pretty
common behavior; in fact *every one* of the existing callers of
WinGetFuncArgInPartition or WinGetFuncArgInFrame does that, at least
conditionally. So I think it's reasonable to have an extra parameter
instead of making a lot of callers reinvent the same wheel.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2009-01-08 14:34:42 | Re: text search patch status update? |
Previous Message | Tom Lane | 2009-01-08 13:55:56 | PQexecParams() returns PGRES_COMMAND_OK for empty query |