2010/2/13 Tom Lane :
> Hitoshi Harada writes:
>> [ more_frame_options patch ]
>
> Committed after rather extensive revisions.
Thanks a lot.
> I'm not terribly happy with the changes you made in WinGetFuncArgInPartition
> and WinGetFuncArgInFrame to force the window function mark to not go
> past
Hitoshi Harada writes:
> [ more_frame_options patch ]
Committed after rather extensive revisions.
I removed the RANGE value PRECEDING/FOLLOWING support as per discussion,
which was probably a good thing anyway from an incremental-development
standpoint; it made it easier to see what was going on
Alvaro Herrera writes:
> Tom Lane escribió:
>> Yeah, I don't immediately see anything that would justify going to
>> that level of effort. Adding +/- as support functions for btree
>> seems like the thing to do.
> Would it work to use a fake access method instead?
Then you'd have to duplicate a
Tom Lane escribió:
> Dimitri Fontaine writes:
> > Searching the archives ain't helping me refresh those memories. So it
> > seems the case for an extended opclass infrastructure, or a new side
> > one, is between thin an non-existent yet?
>
> Yeah, I don't immediately see anything that would just
Dimitri Fontaine writes:
> Searching the archives ain't helping me refresh those memories. So it
> seems the case for an extended opclass infrastructure, or a new side
> one, is between thin an non-existent yet?
Yeah, I don't immediately see anything that would justify going to
that level of effo
Tom Lane writes:
>> I think there's the associativity property of operators that we might
>> want to have someday, in order for the planner to know some more about
>> joins on A = B then on B = C, or replace with < if you will.
>
> We already do know about that, at least in the case of =. The rea
2010/2/12 Tom Lane :
> The real question is whether it's time to bite the bullet and stop
> overloading the opclass infrastructure for semantics-declaration
> purposes. Are there any other foreseeable cases where we are going
> to need to add operator knowledge of this sort?
Table partitioning wi
On Thu, Feb 11, 2010 at 4:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 8, 2010 at 10:37 PM, Hitoshi Harada wrote:
>>> 2010/2/9 Tom Lane :
Given the lack of time remaining in this CF, I'm tempted to propose
ripping out the RANGE support and just trying to get ROWS committ
Dimitri Fontaine writes:
> Tom Lane writes:
>> However, what it *is* associated with is a sort ordering, and the notion
>> that btree opclasses are what define orderings is sufficiently deeply
>> wired into the system that undoing it would be a huge PITA. So unless
>> we can see a pretty clear f
Tom Lane writes:
> However, what it *is* associated with is a sort ordering, and the notion
> that btree opclasses are what define orderings is sufficiently deeply
> wired into the system that undoing it would be a huge PITA. So unless
> we can see a pretty clear future need for more information
Robert Haas writes:
> On Mon, Feb 8, 2010 at 10:37 PM, Hitoshi Harada wrote:
>> 2010/2/9 Tom Lane :
>>> Given the lack of time remaining in this CF, I'm tempted to propose
>>> ripping out the RANGE support and just trying to get ROWS committed.
>>> That should be substantially less controversial
On Thu, 11 Feb 2010, Robert Haas wrote:
On Thu, Feb 11, 2010 at 3:26 PM, Tom Lane wrote:
Martijn van Oosterhout writes:
On Tue, Feb 09, 2010 at 12:37:32PM +0900, Hitoshi Harada wrote:
Now that specialized hard-coding "+"/"-" in source seems unacceptable,
I would like to hear how to handle t
Robert Haas writes:
> On Thu, Feb 11, 2010 at 3:26 PM, Tom Lane wrote:
>> The real question is whether it's time to bite the bullet and stop
>> overloading the opclass infrastructure for semantics-declaration
>> purposes. Are there any other foreseeable cases where we are going
>> to need to add
On Thu, Feb 11, 2010 at 3:26 PM, Tom Lane wrote:
> Martijn van Oosterhout writes:
>> On Tue, Feb 09, 2010 at 12:37:32PM +0900, Hitoshi Harada wrote:
>>> Now that specialized hard-coding "+"/"-" in source seems unacceptable,
>>> I would like to hear how to handle this. Is there any better than
>>>
Martijn van Oosterhout writes:
> On Tue, Feb 09, 2010 at 12:37:32PM +0900, Hitoshi Harada wrote:
>> Now that specialized hard-coding "+"/"-" in source seems unacceptable,
>> I would like to hear how to handle this. Is there any better than
>> introducing new mechanism such like opclass?
> I imagi
On Tue, Feb 09, 2010 at 12:37:32PM +0900, Hitoshi Harada wrote:
> I know "+"/"-" part is an issue. But as far as I know there's been no
> infrastructure to handle such situation. My ideal plan is to introduce
> some mechanism to make "+"/"-" operation abstract enough such like
> sort opclass/opfami
On Mon, Feb 8, 2010 at 10:37 PM, Hitoshi Harada wrote:
> 2010/2/9 Tom Lane :
>> Hitoshi Harada writes:
>>> 2010/1/23 Robert Haas :
Would it make sense to pull some of the infrastructure bits out of
this patch and commit those bits separately, so as to reduce the size
of the main pa
2010/2/9 Tom Lane :
> Hitoshi Harada writes:
>> 2010/1/23 Robert Haas :
>>> Would it make sense to pull some of the infrastructure bits out of
>>> this patch and commit those bits separately, so as to reduce the size
>>> of the main patch? In particular, the AggGetMemoryContext() stuff
>>> looks
I wrote:
> I started looking at this patch. I believe that we should commit the
> AggGetMemoryContext API function --- *not* the window context
> management changes that you included here, but only the API abstraction
> --- to be sure that that gets into 9.0 so that third-party aggregate
> functi
On 2/8/10 11:17 AM, Tom Lane wrote:
> Given the lack of time remaining in this CF, I'm tempted to propose
> ripping out the RANGE support and just trying to get ROWS committed.
> That should be substantially less controversial from a semantic
> standpoint, and it still seems like a considerable imp
Hitoshi Harada writes:
> 2010/1/23 Robert Haas :
>> Would it make sense to pull some of the infrastructure bits out of
>> this patch and commit those bits separately, so as to reduce the size
>> of the main patch? In particular, the AggGetMemoryContext() stuff
>> looks like a good candidate for t
2010/1/23 Robert Haas :
> On Tue, Jan 19, 2010 at 3:02 PM, Hitoshi Harada wrote:
>> 2010/1/19 Hitoshi Harada :
>>> Yeah, that's my point, too. The planner has to distinguish "four" from
>>> sort pathkeys and to teach the executor the simple information which
>>> column should be used to determine
On Tue, Jan 19, 2010 at 3:02 PM, Hitoshi Harada wrote:
> 2010/1/19 Hitoshi Harada :
>> Yeah, that's my point, too. The planner has to distinguish "four" from
>> sort pathkeys and to teach the executor the simple information which
>> column should be used to determine frame. I was bit wrong because
2010/1/19 Hitoshi Harada :
> 2010/1/19 Hitoshi Harada :
>> Yeah, that's my point, too. The planner has to distinguish "four" from
>> sort pathkeys and to teach the executor the simple information which
>> column should be used to determine frame. I was bit wrong because some
>> of current executor
2010/1/19 Hitoshi Harada :
> Yeah, that's my point, too. The planner has to distinguish "four" from
> sort pathkeys and to teach the executor the simple information which
> column should be used to determine frame. I was bit wrong because some
> of current executor code isn't like it, like using or
Hitoshi Harada writes:
> 2010/1/19 Tom Lane :
>> AFAICS that doesn't mean it can't be the
>> canonicalized form of the sort key. If a column is dropped out of the
>> canonical sort key then it's simply redundant, and hence not relevant to
>> determining the range.
> Yeah, that's my point, too. T
2010/1/19 Tom Lane :
> Hitoshi Harada writes:
>> In a RANGE offset mode query, for example:
>
>> SELECT sum(ten) over (PARTITION BY four ORDER BY four RANGE BETWEEN 2
>> PRECEDING AND 1 PRECEDING) FROM tenk1
>
>> the frame is determined as "from the first row which has value
>> - 2 to the last ro
Hitoshi Harada writes:
> 2010/1/17 Tom Lane :
>> That's broken, whether it passes regression tests or not. Not
>> canonicalizing will mean that you fail to recognize equality to
>> canonicalized pathkeys, and thus for example execute unnecessary
>> sorts.
> So why did you leave "canonicalize" ar
2010/1/17 Tom Lane :
> Hitoshi Harada writes:
>> ... I tried to change not to canonicalize the
>> pathkeys in make_pathkeys_window() in such cases and succeeded then
>> passed all regression tests.
>
> That's broken, whether it passes regression tests or not. Not
> canonicalizing will mean that y
Hitoshi Harada writes:
> ... I tried to change not to canonicalize the
> pathkeys in make_pathkeys_window() in such cases and succeeded then
> passed all regression tests.
That's broken, whether it passes regression tests or not. Not
canonicalizing will mean that you fail to recognize equality t
2010/1/17 Erik Rijkers :
> On Sat, January 16, 2010 09:29, Hitoshi Harada wrote:
>> 2010/1/16 Erik Rijkers :
>>>
Thanks for the review. I've found another crash today and attached is
fixed version. The case is:
SELECT four, sum(ten) over (PARTITION BY four ORDER BY four RANGE 1
On Sat, January 16, 2010 09:29, Hitoshi Harada wrote:
> 2010/1/16 Erik Rijkers :
>>
>>> Thanks for the review. I've found another crash today and attached is
>>> fixed version. The case is:
>>>
>>> SELECT four, sum(ten) over (PARTITION BY four ORDER BY four RANGE 1
>>> PRECEDING) FROM tenk1 WHERE u
2010/1/16 Hitoshi Harada :
> 2010/1/16 Erik Rijkers :
>>
>>> Thanks for the review. I've found another crash today and attached is
>>> fixed version. The case is:
>>>
>>> SELECT four, sum(ten) over (PARTITION BY four ORDER BY four RANGE 1
>>> PRECEDING) FROM tenk1 WHERE unique1 < 10;
>>>
>>
>> Hi,
2010/1/16 Erik Rijkers :
>
>> Thanks for the review. I've found another crash today and attached is
>> fixed version. The case is:
>>
>> SELECT four, sum(ten) over (PARTITION BY four ORDER BY four RANGE 1
>> PRECEDING) FROM tenk1 WHERE unique1 < 10;
>>
>
> Hi,
>
> The patch (more_frame_options.2010
> Thanks for the review. I've found another crash today and attached is
> fixed version. The case is:
>
> SELECT four, sum(ten) over (PARTITION BY four ORDER BY four RANGE 1
> PRECEDING) FROM tenk1 WHERE unique1 < 10;
>
Hi,
The patch (more_frame_options.20100115.patch.gz) applies cleanly, but th
2010/1/14 Pavel Stehule :
> Hello
>
> I looked on Hitoshi's patch - and my result is:
Thanks for the review. I've found another crash today and attached is
fixed version. The case is:
SELECT four, sum(ten) over (PARTITION BY four ORDER BY four RANGE 1
PRECEDING) FROM tenk1 WHERE unique1 < 10;
Th
Hello
I looked on Hitoshi's patch - and my result is:
1. Patch is in correct format, it is cleanly applied and compilation
is without warnings,
2. Patch contains adequate changes of doc, and rich set of regress tests,
3. If I could to understand to implemented feature - it is in
conformity with S
37 matches
Mail list logo
