Glenn Maynard wrote:
This rewrite allows getting the top N scores. Unfortunately, this one
takes 950ms for the same data. With 100 scores, it takes 14800ms.
SELECT s.* FROM score s, game g
WHERE s.game_id = g.id AND
s.id IN (
SELECT s2.id FROM score s2 WHERE s2.game_id=g.id ORDER BY
OK, got to my postgres. Here you are:
create or replace function explode_array(in_array anyarray) returns setof
anyelement as
$$
select ($1)[s] from generate_series(1,array_upper($1, 1)) as s;
$$
language sql immutable;
SELECT s.* FROM score s
WHERE s.id IN (
select
-- Get the high
On Apr 8, 2009, at 4:46 PM, Dimitri Fontaine wrote:
$ londiste.py setup.ini provider add schema.table
$ londiste.py setup.ini subscriber add schema.table
That is nice. One could probably do that for slony too.
I may try some tests out with londiste.. I'm always open to new
(ideally,
Hi all,
Has anyone experimented with the Linux deadline parameters and have
some experiences to share?
Regards,
Mark
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Mark Wong mark...@gmail.com wrote:
Has anyone experimented with the Linux deadline parameters and
have some experiences to share?
We've always used elevator=deadline because of posts like this:
http://archives.postgresql.org/pgsql-performance/2008-04/msg00148.php
I haven't benchmarked it,
acording to kernel folks, anticipatory scheduler is even better for dbs.
Oh well, it probably means everyone has to test it on their own at the
end of day.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
On Thu, 9 Apr 2009, Grzegorz Jaśkiewicz wrote:
acording to kernel folks, anticipatory scheduler is even better for dbs.
Oh well, it probably means everyone has to test it on their own at the
end of day.
But the anticipatory scheduler basically makes the huge assumption that
you have one
On Thu, Apr 9, 2009 at 3:32 PM, Matthew Wakeling matt...@flymine.org wrote:
On Thu, 9 Apr 2009, Grzegorz Jaśkiewicz wrote:
acording to kernel folks, anticipatory scheduler is even better for dbs.
Oh well, it probably means everyone has to test it on their own at the
end of day.
But the
Matthew Wakeling matt...@flymine.org wrote:
On Thu, 9 Apr 2009, Grzegorz Jaœkiewicz wrote:
acording to kernel folks, anticipatory scheduler is even better for
dbs. Oh well, it probably means everyone has to test it on their
own at the end of day.
But the anticipatory scheduler basically
Grzegorz Jaœkiewicz gryz...@gmail.com wrote:
(btw, CFQ is the anticipatory scheduler).
These guys have it wrong?:
http://www.wlug.org.nz/LinuxIoScheduler
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
On Thu, 9 Apr 2009, Grzegorz Jaśkiewicz wrote:
(btw, CFQ is the anticipatory scheduler).
No, CFQ and anticipatory are two completely different schedulers. You can
choose between them.
But the anticipatory scheduler basically makes the huge assumption that you
have one single disc in the
On Thu, Apr 9, 2009 at 3:42 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Grzegorz Jaœkiewicz gryz...@gmail.com wrote:
(btw, CFQ is the anticipatory scheduler).
These guys have it wrong?:
http://www.wlug.org.nz/LinuxIoScheduler
sorry, I meant it replaced it :) (is default now).
On 9-4-2009 16:09 Kevin Grittner wrote:
I haven't benchmarked it, but when one of our new machines seemed a
little sluggish, I found this hadn't been set. Setting this and
rebooting Linux got us back to our normal level of performance.
Why would you reboot after changing the elevator? For
On Thu, Apr 9, 2009 at 7:00 AM, Mark Wong mark...@gmail.com wrote:
Hi all,
Has anyone experimented with the Linux deadline parameters and have some
experiences to share?
Hi all,
Thanks for all the responses, but I didn't mean selecting deadline as
much as its parameters such as:
Arjen van der Meijden acmmail...@tweakers.net wrote:
On 9-4-2009 16:09 Kevin Grittner wrote:
I haven't benchmarked it, but when one of our new machines seemed a
little sluggish, I found this hadn't been set. Setting this and
rebooting Linux got us back to our normal level of performance.
On Thu, Apr 9, 2009 at 7:53 AM, Mark Wong mark...@gmail.com wrote:
On Thu, Apr 9, 2009 at 7:00 AM, Mark Wong mark...@gmail.com wrote:
Hi all,
Has anyone experimented with the Linux deadline parameters and have some
experiences to share?
Hi all,
Thanks for all the responses, but I didn't
The anticipatory scheduler gets absolutely atrocious performance for server
workloads on even moderate server hardware. It is applicable only to single
spindle setups on desktop-like worlkoads.
Seriously, never use this for a database. It _literally_ will limit you to
100 iops maximum random
On Thu, Apr 9, 2009 at 7:29 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
SELECT s.* FROM score s, game g
WHERE s.game_id = g.id AND
s.id IN (
SELECT s2.id FROM score s2 WHERE s2.game_id=g.id ORDER BY s2.score
DESC LIMIT 1
);
You don't really need the join with
2009/4/9 Віталій Тимчишин tiv...@gmail.com:
create or replace function explode_array(in_array anyarray) returns setof
anyelement as
$$
select ($1)[s] from generate_series(1,array_upper($1, 1)) as s;
$$
language sql immutable;
I tried using an ARRAY like this, but didn't quite figure out
On Thu, 9 Apr 2009, tiv00 wrote:
create or replace function explode_array(in_array anyarray) returns setof
anyelement as
$$
select ($1)[s] from generate_series(1,array_upper($1, 1)) as s;
$$
language sql immutable;
Note that you can make this function a bit more general by using
Thanks for all of the suggestions so far. I've been trying to reduce the
number of indices I have, but I'm running into a problem. I have a need to
do queries on this table with criteria applied to the date and possibly any
or all of the other key columns. As a reminder, here's my table:
Rainer Mager rai...@vanten.com writes:
So, I need indices that make it fast querying against start_time as well as
all possible combinations of channel, player, and ad.
There's some general principles in the manual --- have you read
http://www.postgresql.org/docs/8.3/static/indexes.html
All,
Wow, am I really the only person here who's used IOZone?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
23 matches
Mail list logo
