dlight == dlight avinf...@gmail.com writes:
dlight So if I run function 1 with varible inside the query in
dlight one session it's replan each time.
dlight But if whant to teling postgres do not doing this, what shoud
dlight i do?
dlight We have more than 1 runs in one session
Robert == Robert Haas robertmh...@gmail.com writes:
bgworker.c: In function 'WaitForBackgroundWorkerStartup':
bgworker.c:866: warning: 'pid' may be used uninitialized in this function
Robert Does the attached patch fix it for you?
It compiles without error and looks ok...
--
Andrew
Heikki == Heikki Linnakangas hlinnakan...@vmware.com writes:
Heikki I've spent some time reviewing this patch - looks pretty
Heikki good! I'm not through yet, but I wanted to post an
Heikki update. Attached is a new version, with some modifications I
Heikki made. Notably:
Heikki I
Merlin == Merlin Moncure mmonc...@gmail.com writes:
Who is pgFoundery administrator or board member now? I would like
to send e-mail them. At least, it does not have information and
support page in pgFoundery homepage.
Merlin I have not been able to get in contact with Marc either to
Pavel == Pavel Stehule pavel.steh...@gmail.com writes:
I found so following error message is not too friendly (mainly because
this functionality will be new)
postgres=# select dense_rank(3,3,2) within group (order by num desc, odd)
from test4;
ERROR: Incorrect number of arguments
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I've been hacking on this patch all day yesterday. What I'm on
Tom about at the moment is reversing the decision to move range
Tom functions' funccoltypes etc into FuncExpr. That's a bad idea on
Tom the grounds of bloating FuncExpr, but the
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom BTW, the reason we need to store the column count explicitly is
Tom that we have to ignore the added columns if a composite type has
Tom had an ADD COLUMN done to it since the RTE was made. The
Tom submitted patch fails rather nastily in such
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Inlining should already check that the type doesn't change as a
result; where exactly is the issue here?
Tom The issue is that if you want to dig column type information out
Tom of a function RTE, that won't necessarily work after
Tom
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom 1. Reinsert HEAD's prohibition against directly combining WITH
Tom ORDINALITY with a coldeflist (with a better error message and a
Tom HINT suggesting that you can get what you want via the TABLE
Tom syntax).
That gets my vote.
--
Andrew
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom and this would result in producing the array elements as a table
Tom column. There is nothing in there about a function returning
Tom set.
In the spec, there is no such thing as a function returning a set of
rows in the sense that we use.
Vik == Vik Fearing vik.fear...@dalibo.com writes:
Vik I certainly want it. I do not have a copy of the SQL standard,
Vik but I have full faith in the Andrew Gierth's claim that this is
Vik part of it.
For reference, this is how I believe it matches up against the spec
(I'm working from the
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Anyway, after further thought I've come up with an approach
Tom that's purely a syntactic transformation and so less likely to
Tom cause surprise: let's say that if we have TABLE() with a single
Tom argument, and no coldeflist either inside or
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I've committed this patch after some significant editorialization, but
Tom leaving the use of TABLE( ... ) syntax in-place. If we decide that we
Tom don't want to risk doing that, we can change to some other syntax later.
Is this intended:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom [ I assume you forgot a create type footype here ]
yeah, sorry
Tom Well, it's not insane on its face. The rowtype of f in the
Tom first example is necessarily a built-on-the-fly record, but in
Tom the second case using the properties of the
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom 1. I really hate the way you've overloaded the transvalue to do
Tom something that has approximately nothing to do with transition
Tom state (and haven't updated catalogs.sgml to explain that,
Tom either). Seems like it'd be cleaner to just
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Well, okay, but you've not said anything that wouldn't be
Tom handled just as well by some logic that adds a fixed
Tom integer-constant-zero flag column to the rows going into the
Tom tuplesort.
Adding such a column unconditionally even for
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Well, sure, but I was only suggesting adding it when the
Tom aggregate asks for it, probably via a new flag column in
Tom pg_aggregate.
Sure, I was only pointing out the necessity.
Tom The question you're evading is what additional
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Further questions about WITHIN GROUP:
Tom I believe that the spec requires that the direct arguments of
Tom an inverse or hypothetical-set aggregate must not contain any
Tom Vars of the current query level.
False.
The spec requires that the
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Regardless of that, though ... what is the reasoning for
Tom inventing pg_get_aggregate_arguments() rather than just making
Tom pg_get_function_arguments() do the right thing?
pg_get_function_arguments()'s interface assumes that the caller is
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Please don't object that that doesn't look exactly like the syntax
for calling the function, because it doesn't anyway --- remember
you also need ORDER BY in the call.
Tom Actually, now that I think of it, why not use this syntax for
Tom
Tom == Tom Lane t...@sss.pgh.pa.us writes:
pg_get_function_arguments()'s interface assumes that the caller is
providing the enclosing parens. Changing it would have meant
returning a result like 'float8) WITHIN GROUP (float8' which I
reckoned would have too much chance of breaking
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Another thing to think about here is to wonder why the committee chose
Tom anything as verbose as agg(...) WITHIN GROUP (ORDER BY ...) in the
Tom first place. The words ORDER BY certainly seem pretty unnecessary.
All of the ordered-set
Josh == Josh Berkus j...@agliodbs.com writes:
Since I don't particularly trust my own judgement on aesthetics, I
used the feedback I got from others when deciding what to
do. Frankly I think this one needs wider input than just you and
me arguing over it.
Josh Can someone paste
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom 2. For an ordered set function, n must equal aggnfixedargs. We
Tom treat all n fixed arguments as contributing to the aggregate's
Tom result collation, but ignore the sort arguments.
That doesn't work for getting a sensible collation out of
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Not wanting to consider the sort args when there's more than one
Tom doesn't square with forcing them to be considered when there's
Tom just one. It's the same aggregate after all,
This logic is only applied in the patch to aggregates that
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom After examining this more closely, ISTM that the direct
Tom arguments are supposed to be processed as if they weren't inside
Tom an aggregate call at all. That being the case, isn't it flat
Tom out wrong for check_agg_arguments() to be
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Hmm... yes, you're probably right; but we'd still have to check
somewhere for improper nesting, no? since not even the direct args
are allowed to contain nested aggregate calls.
Tom Yeah, I had come to that same conclusion while making the
Tom
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom We could alternatively decide that the agg has level 0, but that
Tom doesn't seem terribly useful, and I think it's not per spec
Tom either. SQL:2008 section 6.9 set function specification seems
Tom pretty clear that only aggregated arguments
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I eventually decided that we were overthinking this problem. At
Tom least for regular ordered-set aggregates, we can just deem that
Tom the collation of the aggregate is indeterminate unless all the
Tom inputs (both direct and aggregated) agree
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom What I'm now thinking we want to do is:
Tom 1. Non-hypothetical direct args always contribute to determining
Tom the agg's collation.
Tom 2. Hypothetical and aggregated args contribute to the agg's
Tom collation only if the agg is designed so
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I've committed this after significant editorialization --- most
Tom notably, I pushed control of the sort step into the aggregate
Tom support functions.
Initial tests suggest that your version is ~40% slower than ours on
some workloads.
On my
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Initial tests suggest that your version is ~40% slower than ours on
some workloads.
Tom I poked at this a bit with perf and oprofile, and concluded that
Tom probably the difference comes from ordered_set_startup()
Tom repeating lookups for each
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Furthermore, I can't help noticing that the increased complexity
has now pretty much negated your original arguments for moving so
much of the work out of nodeAgg.c.
Tom The key reason for that was, and remains, not having the
Tom behavior
I've been assisting Atri with development of an implementation of
GROUPING SETS, beginning with a one-pass implementation of ROLLUP.
Two issues have arisen regarding the API for calling aggregate
transition and final functions that I think need answering now,
since they relate to changes in 9.4.
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Doing rollup via GroupAggregate by maintaining multiple transition
values at a time (one per grouping set) means that the transfn is
being called interleaved for transition values in different
contexts. So the question becomes: is it wrong for
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Another approach would be to remove AggGetPerAggEContext as such
Tom from the API altogether, and instead offer an interface that
Tom says register an aggregate cleanup callback, leaving it to the
Tom agg/window core code to figure out which
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Do we want a decision on the fn_extra matter first, or shall I do
one patch for the econtext, and a following one for fn_extra?
Tom I think they're somewhat independent, and probably best patched
Tom separately. In any case orderedsetagg.c's use
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom If we're going to do that, I think it needs to be in 9.4. Are
Tom you going to work up a patch?
How's this? (applies and passes regression on 9.4 and master)
--
Andrew (irc:RhodiumToad)
diff --git a/src/backend/executor/nodeAgg.c
Here are two more, cumulative with the previous patch and each other:
The first removes the assumption in ordered_set_startup that the
aggcontext can be cached in fn_extra, and puts it in the transvalue
instead.
The second exposes the OSA* structures in a header file, so that
user-defined
Tom == Tom Lane t...@sss.pgh.pa.us writes:
How's this? (applies and passes regression on 9.4 and master)
Tom Pushed with minor cosmetic adjustments.
Thanks!
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Spent some time analyzing a severe performance regression on 9.1-9.3
upgrade for a user on IRC. Narrowed it down to this:
commit 807a40c5 fixed a bug in handling of (new in 9.2) functionality
of ScalarArrayOpExpr in btree index quals, forcing the results of
scans including such a qual to be
Tom == Tom Lane t...@sss.pgh.pa.us writes:
I've experimented with the attached patch, which detects when this
situation might have occurred and does another pass to try and
build ordered scans without the SAOP condition. However, the
results may not be quite ideal, because at least in
Heikki == Heikki Linnakangas hlinnakan...@vmware.com writes:
On 08/13/2014 09:43 PM, Atri Sharma wrote:
Sorry, forgot to attach the patch for fixing cube in contrib,
which breaks since we now reserve cube keyword. Please find
attached the same.
Heikki Ugh, that will make everyone using
A progress update:
Atri We envisage that handling of arbitrary grouping sets will be
Atri best done by having the planner generating an Append of
Atri multiple aggregation paths, presumably with some way of moving
Atri the original input path to a CTE. We have not really explored
Atri yet
Heikki == Heikki Linnakangas hlinnakan...@vmware.com writes:
Heikki Uh, that's ugly. The EXPLAIN out I mean; as an implementation
Heikki detail chaining the nodes might be reasonable. But the above
Heikki gets unreadable if you have more than a few grouping sets.
It's good for highlighting
Tom == Tom Lane t...@sss.pgh.pa.us writes:
I agree, the contrib/cube patch as posted is purely so we could test
everything without having to argue over the new name first.
Tom I wonder if you've tried hard enough to avoid reserving the keyword.
GROUP BY cube(a,b) is currently legal
Stephen == Stephen Frost sfr...@snowman.net writes:
I'm inclined to think that the audience for this is far larger
than the audience for the cube extension, which I have not once
encountered in the field.
Stephen +1
Most of my encounters with cube have been me suggesting it to people
on
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Perhaps so. I would really prefer not to have to get into
Tom estimating how many people will be inconvenienced how badly.
Tom It's clear to me that not a lot of sweat has been put into
Tom seeing if we can avoid reserving the keyword, and I
Alvaro == Alvaro Herrera alvhe...@2ndquadrant.com writes:
(This of course means that if someone has a cube() function call
in a group by clause of a view, then upgrading will change the
meaning of the view and possibly fail to create it; there seems to
be no fix for this, not even using
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I'm not convinced of that; I think some creative hackery in the
Tom grammar might be able to deal with this.
Making GROUP BY CUBE(a,b) parse as grouping sets rather than as a
function turned out to be the easy part: give CUBE a lower precedence
Robert == Robert Haas robertmh...@gmail.com writes:
Robert I can accept ugly code, but I feel strongly that we shouldn't
Robert accept ugly semantics. Forcing cube to get out of the way
Robert may not be pretty, but I think it will be much worse if we
Robert violate the rule that quoting a
Pavel == Pavel Stehule pavel.steh...@gmail.com writes:
Pavel Hi
Pavel I checked this patch, and it working very well
Pavel I found only two issue - I am not sure if it is issue
Pavel It duplicate rows
Pavel postgres=# explain select name, place, sum(count), grouping(name),
Pavel
Erik == Erik Rijkers e...@xs4all.nl writes:
Erik The patches did not apply anymore so I applied at 73eba19aebe0.
Erik There they applied OK, and make make check was OK.
I'll look and rebase if need be.
-- WARNING: unrecognized node type: 347
Can't reproduce this - are you sure it's not a
Andrew == Andrew Gierth and...@tao11.riddles.org.uk writes:
Erik == Erik Rijkers e...@xs4all.nl writes:
Erik The patches did not apply anymore so I applied at 73eba19aebe0.
Erik There they applied OK, and make make check was OK.
Andrew I'll look and rebase if need be.
They apply cleanly
Erik == Erik Rijkers e...@xs4all.nl writes:
They apply cleanly for me at 2bde297 whether with git apply or
patch, except for the contrib one (which you don't need unless you
want to run the contrib regression tests without applying the
gsp-u patch).
Erik Ah, I had not realised that.
Tomas == Tomas Vondra t...@fuzzy.cz writes:
Tomas I have significant doubts about the whole design,
Tomas though. Especially the decision not to use HashAggregate,
There is no decision not to use HashAggregate. There is simply no
support for HashAggregate yet.
Having it be able to work with
Tomas == Tomas Vondra t...@fuzzy.cz writes:
It's not one sort per grouping set, it's the minimal number of
sorts needed to express the result as a union of ROLLUP
clauses. The planner code will (I believe) always find the
smallest number of sorts needed.
Tomas You're probably right.
Tomas == Tomas Vondra t...@fuzzy.cz writes:
As for computing it all twice, there's currently no attempt to
optimize multiple identical grouping sets into multiple
projections of a single grouping set result. CUBE(a,b,c,a) has
twice as many grouping sets as CUBE(a,b,c) does, even though
Robert == Robert Haas robertmh...@gmail.com writes:
Robert Sure, showing the sort and aggregation steps is fine. But I
Robert don't see what advantage we get out of showing them like
Robert this:
Robert Aggregate
Robert - Sort
Robert- ChainAggregate
Robert - Sort
Robert
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Honestly, ChainAggregate is _trivial_ compared to trying to make the
GroupAggregate code deal with multiple inputs, or trying to make some
new sort of plumbing node to feed input to those sorts. (You'd think
that it should be possible to use
Tomas == Tomas Vondra t...@fuzzy.cz writes:
Tomas If we can get rid of the excessive ChainAggregate, that's
Tomas certainly enough for now.
I found an algorithm that should provably give the minimal number of sorts
(I was afraid that problem would turn out to be NP-hard, but not so - it's
Marti == Marti Raudsepp ma...@juffo.org writes:
Marti Since you were asking for feedback on the EXPLAIN output on
Marti IRC, I'd weigh in and say that having the groups on separate
Marti lines would be significantly more readable.
I revisited the explain output a bit and have come up with
Marti == Marti Raudsepp ma...@juffo.org writes:
(yaml format)
Grouping Sets:
- - two
- four
- - two
-
Marti Now this is weird.
You're telling me. Also, feeding it to an online yaml-to-json
converter gives the result as [[two,four],[two],null] which is
not quite the same
Andrew == Andrew Gierth and...@tao11.riddles.org.uk writes:
Andrew You're telling me. Also, feeding it to an online yaml-to-json
Andrew converter gives the result as [[two,four],[two],null]
Andrew which is not quite the same as the json version. An
Andrew alternative would be:
Oh, another
Josh == Josh Berkus j...@agliodbs.com writes:
Josh (b) If we're going to discuss ripping out YAML format, please
Josh let's do that as a *separate* patch and discussion,
+infinity
Grouping Sets:
- [two,four]
- [two]
- []
Would that be better? (It's not consistent with
Adam == Brightwell, Adam adam.brightw...@crunchydatasolutions.com
writes:
Adam At any rate, this appears to be a previously existing issue
Adam with WITH CHECK OPTION. Thoughts?
It's definitely an existing issue; you can reproduce it more simply,
no need to mess with different users.
The
bill == bill wilson bill.wilson.h...@gmail.com writes:
bill This a toy example from a 'upsert' script that appends new data:
bill select a from (select 1 as a) as t1 where not exists (select
bill true from (select 2 as a) t2 where a=a) ;
bill a
bill ───
bill (0 rows)
bill Please tell me
Pavel == Pavel Stehule pavel.steh...@gmail.com writes:
Pavel Hi
Pavel I tried to solve following task:
Pavel I have a table
Pavel start, reason, km
Pavel =
Pavel 2014-01-01 08:00:00, private, 10
Pavel 2014-01-01 09:00:00, commerc, 20
Pavel 2014-01-01 10:00:00, commerc,
Heikki == Heikki Linnakangas hlinnakan...@vmware.com writes:
Heikki There's been a lot of discussion and I haven't followed it in
Heikki detail. Andrew, there were some open questions, but have you
Heikki gotten enough feedback so that you know what to do next?
I was holding off on posting a
This is from Bug #11555, which is still in moderation as I type this
(analysis was done via IRC).
The GiST insertion code appears to have no length checks at all on the
inserted entry. index_form_tuple checks for length = 8191, with the
default blocksize, but obviously a tuple less than 8191
Tom == Tom Lane t...@sss.pgh.pa.us writes:
The spec clearly says one value per row, not one per statement;
so command ID is very definitely not the right thing.
I think (command ID, estate-es_processed) would work.
Tom Not terribly well, eg each new transaction starts over at
Tom
Bruce == Bruce Momjian br...@momjian.us writes:
Bruce Uh, did this ever get addressed?
It did not.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alex == Alex Shulgin a...@commandprompt.com writes:
Tom Lane t...@sss.pgh.pa.us writes:
Must've been my evil twin.
Alex Sorry, I must be under false impression that RhodiumToad is
Alex *your* nick on #postgresql at freenode. I don't recall who
Alex told me that, but I was pretty sure
Tom == Tom Lane t...@sss.pgh.pa.us writes:
What that code does is produce plans that look like this:
GroupAggregate
- Sort
- ChainAggregate
- Sort
- ChainAggregate
in much the same way that WindowAgg nodes are generated.
Tom That seems pretty messy, especially
Tom == Tom Lane t...@sss.pgh.pa.us writes:
I'd already explained in more detail way back when we posted the
patch. But to reiterate: the ChainAggregate nodes pass through
their input data unchanged, but on group boundaries they write
aggregated result rows to a tuplestore shared by the
Just got a report on IRC of a bug in the array version of
percentile_cont; if two of the requested percentiles were between the
same pair of input rows, the result could be wrong or an error would
be generated.
e.g.
select percentile_cont(array[0.4,0.6]) within group (order by gs)
from
Tom == Tom Lane t...@sss.pgh.pa.us writes:
With the high-priority questions out of the way, time to tackle the
rest:
Tom My single biggest complaint is about the introduction of struct
Tom GroupedVar. If we stick with that, we're going to have to teach
Tom an extremely large number of
Fujii == Fujii Masao masao.fu...@gmail.com writes:
Fujii Pushed.
Bug found:
regression=# select count(*) from generate_series(1::numeric,10) v,
generate_series(1,v) w;
count
---
0
(1 row)
regression=# select count(*) from generate_series(1::numeric,10) v,
generate_series(1,v+0)
Michael == Michael Paquier michael.paqu...@gmail.com writes:
Michael Based on those comments, I am marking this patch as
Michael Returned with Feedback on the CF app for 2014-10. Andrew,
Michael feel free to move this entry to CF 2014-12 if you are
Michael planning to continue working on it
Ali == Ali Akbar the.ap...@gmail.com writes:
Ali I think yes, it will be good. The alternative is restructuring
Ali this paragraph in the SRF docs:
The memory context that is current when the SRF is called is a
transient context that will be cleared between calls. This means
that you
Heikki == Heikki Linnakangas hlinnakan...@vmware.com writes:
Heikki Looking at the weighed_stats code, this probably illustrates
Heikki the hoops you had to jump through:
Actually that hoop-jumping expression is almost irrelevant.
The part that hurts (and yes, it's performance that's at
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Hmm. You'd want to make add_var, mul_var etc. non-static?
Tom -1 for that.
possibly with more meaningful names.
Tom If you're concerned about arithmetic performance, there is a
Tom very obvious fix here: use double.
Independently of this
Tom == Tom Lane t...@sss.pgh.pa.us writes:
[Noah]
I caution against using window function performance as the
template for GROUPING SETS performance goals. The benefit of
GROUPING SETS compared to its UNION ALL functional equivalent is
15% syntactic pleasantness, 85% performance
Robert == Robert Haas robertmh...@gmail.com writes:
I would be interested in seeing more good examples of the size and
type of grouping sets used in typical queries.
Robert From what I have seen, there is interest in being able to do
Robert things like GROUP BY CUBE(a, b, c, d) and have
Greg == Greg Sabino Mullane g...@turnstep.com writes:
Greg I am working on enhancing the ping() method of DBD::Pg. The
Greg goal of that is for a user to be able to determine if the
Greg connection to the database is still valid. The basic way we do
Greg this is to send a simple SELECT via
Noah == Noah Misch n...@leadboat.com writes:
Noah Suppose one node orchestrated all sorting and aggregation.
Well, that has the downside of making it into an opaque blob, without
actually gaining much.
Noah Call it a MultiGroupAggregate for now. It wouldn't harness
Noah Sort nodes, because
[pruning the Cc: list and starting a new thread]
Here's the cleaned-up version of the patch to allow abbreviated keys
when sorting a single Datum. This also removes comments that suggest
that the caller of tuplesort_begin_datum should ever have to care
about the abbreviated key optimization.
Kyotaro == Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp writes:
Kyotaro Hmm. The mail address indeed *was* mine but is now obsolete,
Kyotaro so that the email might bounce. But I haven't find how to
Kyotaro change it within the app itself, and the PostgreSQL community
Kyotaro account
Robert == Robert Haas robertmh...@gmail.com writes:
Robert All right, it seems Tom is with you on that point, so after
Robert some study, I've committed this with very minor modifications.
This caught my eye (thanks to conflict with GS patch):
* In the future, we should consider forcing the
Robert == Robert Haas robertmh...@gmail.com writes:
Robert All right, it seems Tom is with you on that point, so after
Robert some study, I've committed this with very minor modifications.
While hacking up a patch to demonstrate the simplicity of extending this
to the Datum sorter, I seem to
Peter == Peter Geoghegan p...@heroku.com writes:
Peter You'll probably prefer the attached. This patch works by
Peter disabling abbreviation, but only after writing out runs, with
Peter the final merge left to go. That way, it doesn't matter when
Peter abbreviated keys are not read back from
Peter == Peter Geoghegan p...@heroku.com writes:
Peter Basically, the intersection of the datum sort case with
Peter abbreviated keys seems complicated.
Not to me. To me it seems completely trivial.
Now, I follow this general principle that someone who is not doing the
work should never say
Correct me if I'm wrong, but is it not the case that:
1) pg_standby was intended to be customizable code, even if usable as
distributed, and
2) in any event it is essentially deprecated in favour of standby_mode
and therefore moving it to src/bin seems like a wrong move on two counts?
--
Robert == Robert Haas robertmh...@gmail.com writes:
Here's the cleaned-up version of the patch to allow abbreviated keys
when sorting a single Datum. This also removes comments that suggest
that the caller of tuplesort_begin_datum should ever have to care
about the abbreviated key
Peter == Peter Geoghegan p...@heroku.com writes:
Peter The mailing list integration is good, but seems like it could
Peter often be overkill. I just want to tag an existing message for
Peter readability here, like with the old commitfest app. I like to
Peter make things easy to find from the
Happened to notice this:
postgres=# select numeric_send('NaN');
numeric_send
\x7f7ec000
(1 row)
7f7e obviously screams accessing memory beyond the end of data, and
indeed this is so: init_var_from_num, when passed a NaN, accesses two
bytes after the input.
Peter == Peter Geoghegan p...@heroku.com writes:
Peter What I find particularly interesting about this patch is that it
Peter makes sorting numerics significantly faster than even sorting
Peter float8 values,
I get a much smaller difference there than you do.
Obvious overheads in float8
Peter == Peter Geoghegan p...@heroku.com writes:
Peter What I find particularly interesting about this patch is that it
Peter makes sorting numerics significantly faster than even sorting
Peter float8 values,
Played some more with this. Testing on some different gcc versions
showed that the
Tom == Tom Lane t...@sss.pgh.pa.us writes:
A quick test suggests that initializing the hash value to ~0 rather
than 0 has a curious effect: the number of batches still explodes,
but the performance does not suffer the same way. (I think because
almost all the batches end up empty.) I
This came up today on IRC, though I suspect the general problem has been
seen before:
create table m3 (id uuid, status integer);
create table q3 (id uuid);
insert into m3
select uuid_generate_v4(), floor(random() * 4)::integer
from generate_series(1,100);
insert into q3
select id
201 - 300 of 488 matches
Mail list logo
