Grzegorz Jaskiewicz 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.
In my test case, noop and deadline performed well, deadline being a little
better than noop.
Both anticipato
All,
I was looking at these IOZone results for some NAS hardware and thinking
about index scans:
Children see throughput for 6 readers = 72270.04 KB/sec
Parent sees throughput for 6 readers = 72269.06 KB/sec
Min throughput per process = 11686.53
Josh Berkus wrote:
All,
Wow, am I really the only person here who's used IOZone?
No - I used to use it exclusively, but everyone else tended to demand I
redo stuff with bonnie before taking any finding seriously... so I've
kinda 'submitted to the Borg' as it were
--
Sent via pgsql-per
On Thu, Apr 9, 2009 at 7:29 AM, Heikki Linnakangas
wrote:
> CREATE FUNCTION topnscores(game_id int , n int) RETURNS SETOF score LANGUAGE
> SQL AS $$
> SELECT * FROM score s WHERE s.game_id = $1 ORDER BY score DESC LIMIT $2
> $$;
>
> SELECT (sub.ts).id, (sub.ts).score, (sub.ts).game_id
> FROM (SELE
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
"Rainer Mager" 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
especially 11.3 and 1
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:
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
array_lo
2009/4/9 Віталій Тимчишин :
> 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 the
explod
On Thu, Apr 9, 2009 at 7:29 AM, Heikki Linnakangas
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 game here, simplifying th
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 acc
On Thu, Apr 9, 2009 at 7:53 AM, Mark Wong wrote:
> On Thu, Apr 9, 2009 at 7:00 AM, Mark Wong 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
Arjen van der Meijden 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.
>
> Why would you r
On Thu, Apr 9, 2009 at 7:00 AM, Mark Wong 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:
antic_expire
read_batch_e
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 2.6-
On Thu, Apr 9, 2009 at 3:42 PM, Kevin Grittner
wrote:
> Grzegorz Jaœkiewicz 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).
--
GJ
--
Sent via pgsql-performance
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 sys
Grzegorz Jaœkiewicz 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:
http://www.postgresql.org/ma
Matthew Wakeling 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 makes the hu
On Thu, Apr 9, 2009 at 3:32 PM, Matthew Wakeling 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
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 single
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:
http://www.postgresql.org
Mark Wong 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, but when one of
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
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, bet
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 s
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 scorin
27 matches
Mail list logo
