Tom Lane wrote:
argue that there was a regression. It's certainly a performance bug
though: nobody would expect that giving a query *more* work_mem would
cause it to run many times slower.
I wouldn't be that surprised - otherwise it'd just be hard-coded to
something large.
Especially since
2010/12/10 Tom Lane t...@sss.pgh.pa.us:
I wrote:
We're throwing away one tuple at a time as we advance forward through
the tuplestore, and moving 10+ tuple pointers each time. Ugh.
This code was all right when written, because (IIRC) the mergejoin
case was actually the only caller. But
Hitoshi Harada umi.tan...@gmail.com writes:
I see it's too late now that you've committed it,
Patches can always be reverted...
but it seems there
was another way to avoid it by not trimming from percent_rank()
individually. Once the whole partition is fit to the memory, you don't
need to
2010/12/11 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com writes:
I see it's too late now that you've committed it,
Patches can always be reverted...
but it seems there
was another way to avoid it by not trimming from percent_rank()
individually. Once the whole partition
Hitoshi Harada umi.tan...@gmail.com writes:
Hm? Once percent_rank() scans to the partition end, any other window
functions that scans row by row don't need to care the memory
reduction, aren't they? Or more generally, if the partition was
scanned to the end, we don't need to trim tuplestore
Hi all,
I'm new to window functions. Recently I run some simple queries but
surprised to find percent_rank is so slower than rank, could anybody tell me
why?
The table schema:
test=# \d inventory1
Table public.inventory1
Column| Type | Modifiers
Jie Li jay23j...@gmail.com writes:
I'm new to window functions. Recently I run some simple queries but
surprised to find percent_rank is so slower than rank, could anybody tell me
why?
Huh, interesting. I can reproduce this with toy data, such as
create table inventory1 (inv_date_sk int,
I wrote:
We're throwing away one tuple at a time as we advance forward through
the tuplestore, and moving 10+ tuple pointers each time. Ugh.
This code was all right when written, because (IIRC) the mergejoin
case was actually the only caller. But it's not all right for
WindowAgg's
Tom Lane t...@sss.pgh.pa.us wrote:
I'm not sure whether or not to back-patch this into 9.0 and 8.4.
The code in tuplestore.c hasn't changed at all since 8.4, so
there's not much risk of cross-version bugs, but if I did miss
anything we could be shipping a buggy version next week.
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
I'm not sure whether or not to back-patch this into 9.0 and 8.4.
The code in tuplestore.c hasn't changed at all since 8.4, so
there's not much risk of cross-version bugs, but if I did miss
anything we could
Tom Lane t...@sss.pgh.pa.us wrote:
Do you have reason to think that anybody is likely to exercise
window functions in HEAD, beyond what the regression tests do, in
the next couple of months?
Not specifically, no. From the description (not having read the
patch) I was somewhat concerned
On Thu, Dec 09, 2010 at 05:18:57PM -0500, Tom Lane wrote:
I wrote:
We're throwing away one tuple at a time as we advance forward through
the tuplestore, and moving 10+ tuple pointers each time. Ugh.
This code was all right when written, because (IIRC) the mergejoin
case was actually
12 matches
Mail list logo
