Tom Lane t...@sss.pgh.pa.us 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
Dimitri Fontaine dfonta...@hi-media.com 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
Tom Lane escribió:
Dimitri Fontaine dfonta...@hi-media.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
Hitoshi Harada umi.tan...@gmail.com 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
2010/2/13 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com 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
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/opfamily,
Martijn van Oosterhout klep...@svana.org 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
On Thu, Feb 11, 2010 at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Martijn van Oosterhout klep...@svana.org 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
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 11, 2010 at 3:26 PM, Tom Lane t...@sss.pgh.pa.us 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
On Thu, 11 Feb 2010, Robert Haas wrote:
On Thu, Feb 11, 2010 at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Martijn van Oosterhout klep...@svana.org writes:
On Tue, Feb 09, 2010 at 12:37:32PM +0900, Hitoshi Harada wrote:
Now that specialized hard-coding +/- in source seems unacceptable,
I
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 8, 2010 at 10:37 PM, Hitoshi Harada umi.tan...@gmail.com wrote:
2010/2/9 Tom Lane t...@sss.pgh.pa.us:
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.
Tom Lane t...@sss.pgh.pa.us 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
Dimitri Fontaine dfonta...@hi-media.com writes:
Tom Lane t...@sss.pgh.pa.us 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
On Thu, Feb 11, 2010 at 4:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 8, 2010 at 10:37 PM, Hitoshi Harada umi.tan...@gmail.com wrote:
2010/2/9 Tom Lane t...@sss.pgh.pa.us:
Given the lack of time remaining in this CF, I'm tempted to propose
2010/2/12 Tom Lane t...@sss.pgh.pa.us:
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
Hitoshi Harada umi.tan...@gmail.com writes:
2010/1/23 Robert Haas robertmh...@gmail.com:
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
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
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
functions
2010/2/9 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com writes:
2010/1/23 Robert Haas robertmh...@gmail.com:
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
On Mon, Feb 8, 2010 at 10:37 PM, Hitoshi Harada umi.tan...@gmail.com wrote:
2010/2/9 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com writes:
2010/1/23 Robert Haas robertmh...@gmail.com:
Would it make sense to pull some of the infrastructure bits out of
this patch and commit
On Tue, Jan 19, 2010 at 3:02 PM, Hitoshi Harada umi.tan...@gmail.com wrote:
2010/1/19 Hitoshi Harada umi.tan...@gmail.com:
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
2010/1/23 Robert Haas robertmh...@gmail.com:
On Tue, Jan 19, 2010 at 3:02 PM, Hitoshi Harada umi.tan...@gmail.com wrote:
2010/1/19 Hitoshi Harada umi.tan...@gmail.com:
Yeah, that's my point, too. The planner has to distinguish four from
sort pathkeys and to teach the executor the simple
2010/1/19 Hitoshi Harada umi.tan...@gmail.com:
2010/1/19 Hitoshi Harada umi.tan...@gmail.com:
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
2010/1/19 Hitoshi Harada umi.tan...@gmail.com:
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
Hitoshi Harada umi.tan...@gmail.com writes:
2010/1/17 Tom Lane t...@sss.pgh.pa.us:
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
2010/1/19 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com 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
Hitoshi Harada umi.tan...@gmail.com writes:
2010/1/19 Tom Lane t...@sss.pgh.pa.us:
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.
2010/1/16 Erik Rijkers e...@xs4all.nl:
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
2010/1/16 Hitoshi Harada umi.tan...@gmail.com:
2010/1/16 Erik Rijkers e...@xs4all.nl:
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
On Sat, January 16, 2010 09:29, Hitoshi Harada wrote:
2010/1/16 Erik Rijkers e...@xs4all.nl:
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
2010/1/17 Erik Rijkers e...@xs4all.nl:
On Sat, January 16, 2010 09:29, Hitoshi Harada wrote:
2010/1/16 Erik Rijkers e...@xs4all.nl:
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
Hitoshi Harada umi.tan...@gmail.com 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
2010/1/17 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com 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
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 the
2010/1/14 Pavel Stehule pavel.steh...@gmail.com:
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
36 matches
Mail list logo
