data with an index
search, which I'd expect to help many uses of rank(); I assume that's
just hard to implement.
I'll probably be implementing the "temporary functions" approach
tonight, to help Postgres optimize the function. Maybe some day,
Postgres will be able to inlin
On Thu, Feb 4, 2010 at 4:09 AM, Glenn Maynard wrote:
> But I'll be dropping this db into 8.4 soon to see if it helps
> anything, and I'll check again (and if it's still slow I'll post more
> details). It's been a while and I might just have been doing
> som
this db into 8.4 soon to see if it helps
anything, and I'll check again (and if it's still slow I'll post more
details). It's been a while and I might just have been doing
something wrong.
--
Glenn Maynard
--
Sent via pgsql-performance mailing list (pgsql-performance@pos
I see "Inline simple set-returning SQL functions in
FROM clauses" in the 8.4 changelog; I'm not sure if that applies to
this, since this set-returning SQL function isn't in the FROM clause.
--
Glenn Maynard
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
rrect row numbers.
Someone suggested window functions for this back when I was designing
it, and I looked at them. I recall it being very slow, always doing a
seq scan, and it seemed like this wasn't quite what windowing was
designed for...
--
Glenn Maynard
--
Sent via pgsql-performance mailin
On Mon, Feb 1, 2010 at 6:15 AM, Yeb Havinga wrote:
> Glenn Maynard wrote:
>> SELECT highscores_for_steps_and_card(s.id, 591, 1) FROM stomp_steps s;
>> Seq Scan on stomp_steps s (cost=0.00..793.52 rows=2902 width=4)
>> (actual time=26509.919..26509.919 rows=0 loops=1)
>&g
useful (and I don't know any practical alternative), but it's
difficult to profile since it doesn't play nice with EXPLAIN ANALYZE.
--
Glenn Maynard
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
dn't be an issue. Am I missing something here?
test(N) starts N clients, each client creates a single connection and
hammers the server for a while on that connection. test(N) is run for
N=1,2,4,8...256. This seems like a very reasonable test scenario.
--
Glenn Maynard
--
Sent via pg
tion is so much slower; in that case, it *will* serialize
against the disk (by default).
--
Glenn Maynard
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
ocumentation only discusses using prepared statements to
eliminate redundant planning costs. (I'm sure it's mentioned in the
API docs and elsewhere, but if it's a major intended use of PREPARE,
the PREPARE documentation should make note of it.)
--
Glenn Maynard
--
Sent via p
on dates and timestamps than on simple integers.
Of course, you still need to get it in that format. Be careful to
include any parsing you're doing to create the binary date in the
benchmarks. Inevitably, at least part of the difference will be costs
simply moving from the psql proces
with no I/O
for things like constraint checks that need to be done before the
command can return success).
--
Glenn Maynard
#include
#include
#include
main()
{
int parent[2];
int ret = pipe(parent);
assert(ret != -1);
int child[2];
ret = pipe(child);
ote:
> Also, just to be clear: were the "40 insert" cases 40 separate
> transactions or one transaction? I think the latter was meant but
> it's not 100% clear.
One transaction--the only case where I ran more than one transaction
was the first.
--
Glenn May
0 rows/insert: 0.18s
>> one 4-value insert: 0.16s
>> 40 prepared inserts, 100 rows/insert: 0.15s
>
> are one of these missing a 0?
Sorry, 400 * 100. All cases inserted 4 rows, and I deleted all
rows between tests (but did not recreate the table).
--
Glenn Maynard
tements, and if that's not enough, skip to COPY.
--
Glenn Maynard
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
RIAL NOT NULL PRIMARY KEY, score REAL,
game_id INTEGER REFERENCES game (id));
(I don't think it makes any difference to whether this can be
optimized, but adding NOT NULL back to game_id doesn't change it,
either.)
--
Glenn Maynard
--
Sent via pgsql-performance mailing list (pgsql-perfor
. Is there an equivalent way to do this so I won't have
deprecation looming over my back? I'm likely to become very dependent
on this pattern.
--
Glenn Maynard
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
;t quite figure out the
explode_array piece.
--
Glenn Maynard
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
b;
("as ts", for anyone trying this at home)
Thanks--this one runs in 32ms, which seems about right compared
against the original fast LIMIT 1 version.
I see a slight improvement if I mark the function stable: 31.9ms to
31.2; minor but consistent. Just out of curiosity, any explan
unately, with N = 1 this takes 8100ms (vs. 950ms and 25ms)...
--
Glenn Maynard
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
than 1?
(It'd even be faster to make several calls to the first version,
varying an OFFSET to get each high score--but that's terrible.)
--
Glenn Maynard
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www
21 matches
Mail list logo
