Re: [PERFORM] Nested query performance issue
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 s2.score DESC LIMIT 1 ); You don't really need the join with game here, simplifying this into: SELECT s.* FROM score s WHERE s.id IN ( SELECT s2.id FROM score s2 WHERE s2.game_id=s.game_id ORDER BY s2.score DESC LIMIT 1 ); I don't think it makes it any faster, though. You can also do this in a very nice and clean fashion using the upcoming PG 8.4 window functions: SELECT * FROM ( SELECT s.*, rank() OVER (PARTITION BY s.game_id ORDER BY score DESC) AS rank FROM score s ) AS sub WHERE rank = 5; but I'm not sure how much faster it is. At least here on my laptop it does a full index scan on score, which may or may not be faster than just picking the top N values for each game using the index. This seems simple: for each game, search for the highest score, and then scan the tree to get the next N-1 highest scores. The first version does just that, but the second one is doing a seq scan over score. You can do that approach with a SQL function: 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 (SELECT topnscores(g.id, 5) ts FROM game g) sub; -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Nested query performance issue
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 scoring score ID for each game: explode_array(ARRAY( -- Get the high score for game g: SELECT s2.id FROM score s2 WHERE s2.game_id = g.id ORDER BY s2.score DESC LIMIT 5 )) FROM game g ); It takes ~64ms for me Best regards, Vitaliy Tymchyshyn
Re: [PERFORM] Best replication solution?
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, better) things. This could happen in Londiste too, just set pgq_lazy_fetch to a reasonable value and Londiste will use a cursor to fetch the events, lowering the load. Events are just tuples in an INSERT only table, which when not used anymore is TRUNCATEd away. PGQ will use 3 tables where to store events and will rotate its choice of where to insert new envents, allowing to use TRUNCATE rather than DELETE. And PostgreSQL is quite efficient to manage this :) http://wiki.postgresql.org/wiki/Londiste_Tutorial#Londiste_is_eating_all_my_CPU_and_lag_is_raising Well, Slony always uses a cursor to fetch, the problem is it may have to slog through millions of rows to find the new data - I've analyzed the queries and there isn't much it can do - lots of calls to the xxid_ functions to determine whats to be used, whats not to be used. When all slaves have a sync event ack'd it is free to be removed by the cleanup routine which is run every few minutes. Oh and some people asked what Londiste with failover and DDL would look like. Here's what the API being cooked looks like at the moment: $ londiste setup.ini execute myddl.script.sql $ londiste conf/londiste_db3.ini change-provider --provider=rnode1 $ londiste conf/londiste_db1.ini switchover --target=rnode2 ok, so londiste can't do failover yet, or is it just somewhat convoluted at this point? -- Jeff Trout j...@jefftrout.com http://www.stuarthamm.net/ http://www.dellsmartexitin.com/ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
[PERFORM] linux deadline i/o elevator tuning
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
Re: [PERFORM] linux deadline i/o elevator tuning
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, 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. -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] linux deadline i/o elevator tuning
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/mailpref/pgsql-performance
Re: [PERFORM] linux deadline i/o elevator tuning
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 disc in the system that takes a long time to seek from one place to another. This assumption fails on both RAID arrays and SSDs, so I'd be interested to see some numbers to back that one up. Matthew -- import oz.wizards.Magic; if (Magic.guessRight())... -- Computer Science Lecturer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] linux deadline i/o elevator tuning
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 anticipatory scheduler basically makes the huge assumption that you have one single disc in the system that takes a long time to seek from one place to another. This assumption fails on both RAID arrays and SSDs, so I'd be interested to see some numbers to back that one up. (btw, CFQ is the anticipatory scheduler). no they not. They only assume that application reads blocks in synchronous fashion, and that data read in block N will determine where the N+1 block is going to be. So to avoid possible starvation problem, it will wait for short amount of time - in hope that app will want to read possibly next block on disc, and putting that request at the end of queue could potentially starve it. (that reason alone is why 2.6 linux feels so much more responsive). -- GJ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] linux deadline i/o elevator tuning
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 makes the huge assumption that you have one single disc in the system that takes a long time to seek from one place to another. This assumption fails on both RAID arrays and SSDs, so I'd be interested to see some numbers to back that one up. Yeah, we're running on servers with at least 4 effective spindles, with some servers having several dozen effective spindles. Assuming one is not very effective. The setting which seemed sluggish for our environment was the anticipatory scheduler, so the kernel guys apparently aren't thinking about the type of load we have on the hardware we have. -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] linux deadline i/o elevator tuning
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: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] linux deadline i/o elevator tuning
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 system that takes a long time to seek from one place to another. This assumption fails on both RAID arrays and SSDs, so I'd be interested to see some numbers to back that one up. So to avoid possible starvation problem, it will wait for short amount of time - in hope that app will want to read possibly next block on disc, and putting that request at the end of queue could potentially starve it. (that reason alone is why 2.6 linux feels so much more responsive). This only actually helps if the assumptions I stated above are true. Anticipatory is an opportunistic scheduler - it actually witholds requests from the disc as you describe, in the hope that a block will be fetched soon right next to the last one. However, if you have more than one disc, then witholding requests means that you lose the ability to perform more than one request at once. Also, it assumes that it will take longer to seek to the next real request that it will for the program to issue its next request, which is broken on SSDs. Anticipatory attempts to increase performance by being unfair - it is essentially the opposite of CFQ. Matthew -- Now you see why I said that the first seven minutes of this section will have you looking for the nearest brick wall to beat your head against. This is why I do it at the end of the lecture - so I can run. -- Computer Science lecturer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] linux deadline i/o elevator tuning
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). -- GJ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] linux deadline i/o elevator tuning
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-kernels, it can be adjusted on-the-fly for each device separately (echo 'deadline' /sys/block/sda/queue/scheduler). I saw a nice reduction in load and slowness too after adjusting the cfq to deadline for a machine that was at its maximum I/O-capacity on a raid-array. Apart from deadline, 'noop' should also be interesting for RAID and SSD-owners, as it basically just forwards the I/O-request to the device and doesn't do much (if any?) scheduling. Best regards, Arjen -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] linux deadline i/o elevator tuning
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: antic_expire read_batch_expire read_expire write_batch_expire write_expire 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
Re: [PERFORM] linux deadline i/o elevator tuning
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. Why would you reboot after changing the elevator? For 2.6-kernels, it can be adjusted on-the-fly for each device separately (echo 'deadline' /sys/block/sda/queue/scheduler). On the OS where this happened, not yet an option: kgri...@dbutl-pg:~ cat /proc/version Linux version 2.6.5-7.315-bigsmp (ge...@buildhost) (gcc version 3.3.3 (SuSE Linux)) #1 SMP Wed Nov 26 13:03:18 UTC 2008 kgri...@dbutl-pg:~ ls -l /sys/block/sda/queue/ total 0 drwxr-xr-x 2 root root0 2009-03-06 15:27 iosched -rw-r--r-- 1 root root 4096 2009-03-06 15:27 nr_requests -rw-r--r-- 1 root root 4096 2009-03-06 15:27 read_ahead_kb On machines built more recently than the above, I do see a scheduler entry in the /sys/block/sda/queue/ directory. I didn't know about this enhancement, but I'll keep it in mind. Thanks for the tip! Apart from deadline, 'noop' should also be interesting for RAID and SSD-owners, as it basically just forwards the I/O-request to the device and doesn't do much (if any?) scheduling. Yeah, I've been tempted to give that a try, given that we have BBU cache with write-back. Without a performance problem using elevator, though, it hasn't seemed worth the time. -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] linux deadline i/o elevator tuning
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 mean selecting deadline as much as its parameters such as: antic_expire read_batch_expire read_expire write_batch_expire write_expire And I dumped the parameters for the anticipatory scheduler. :p Here are the deadline parameters: fifo_batch front_merges read_expire write_expire writes_starved 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
Re: [PERFORM] linux deadline i/o elevator tuning
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 access iops by waiting 10ms for 'nearby' LBA requests. For Postgres, deadline, cfq, and noop are the main options. Noop is good for ssds and a few high performance hardware caching RAID cards (and only a few of the good ones), and poor otherwise. Cfq tends to favor random access over sequential access in mixed load environments and does not tend to favor reads over writes. Because it batches its elevator algorithm by requesting process, it becomes less efficient with lots of spindles where multiple processes have requests from nearby disk regions. Deadline tends to favor reads over writes and slightly favor sequential access to random access (and gets more MB/sec on average as a result in mixed loads). It tends to work well for large stand-alone servers and not as well for desktop/workstation type loads. I have done a little tuning of the parameters of cfq and deadline, and never noticed much difference. I suppose you could shift the deadline biases to read or write with these. On 4/9/09 7:27 AM, Grzegorz Jaśkiewicz gryz...@gmail.com 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. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Nested query performance issue
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 game here, simplifying this into: SELECT s.* FROM score s WHERE s.id IN ( SELECT s2.id FROM score s2 WHERE s2.game_id=s.game_id ORDER BY s2.score DESC LIMIT 1 ); I don't think it makes it any faster, though. It's about 10% faster for me. I'm surprised the planner can't figure out that this join is redundant. SELECT * FROM ( SELECT s.*, rank() OVER (PARTITION BY s.game_id ORDER BY score DESC) AS rank FROM score s ) AS sub WHERE rank = 5; but I'm not sure how much faster it is. At least here on my laptop it does a full index scan on score, which may or may not be faster than just picking the top N values for each game using the index. I'll definitely check this out when 8.4 is released. You can do that approach with a SQL function: 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 (SELECT topnscores(g.id, 5) ts FROM game g) sub; (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 explanations for this difference? I don't see any change in the resulting query plan, but the plan doesn't enter the function call. -- 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
Re: [PERFORM] Nested query performance issue
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 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
Re: [PERFORM] Nested query performance issue
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_lower as the bottom bound: create or replace function explode_array(in_array anyarray) returns setof anyelement as $$ select ($1)[s] from generate_series (array_lower($1, 1), array_upper($1, 1)) as s; $$ language sql immutable; While you won't run into them in most situations, it is possible to create arrays where the lower bound isn't 1 by using the subscript syntax. The example in the manual even shows that somewhat odd possibilities like assigning something to myarray[-2:7] works. As already pointed out, once you're in 8.4 the windowing functions might be a better fit here, but 8.4 does have unnest built-in that replaces the need to code this sort of thing yourself. You might want to name this function accordingly to match that upcoming standard (or not, depending on whether you want to avoid or be reminding of the potential for using the built-in). See http://www.depesz.com/index.php/2008/11/14/waiting-for-84-array-aggregate-and-array-unpacker/ for some examples. -- * Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] difficulties with time based queries
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:
Table public.ad_log
Column |Type |
Modifiers
+-+-
---
ad_log_id | integer | not null default
nextval('ad_log_ad_log_id_seq'::regclass)
channel| integer | not null
player | integer | not null
ad | integer | not null
start_time | timestamp without time zone |
end_time | timestamp without time zone |
So, I need indices that make it fast querying against start_time as well as
all possible combinations of channel, player, and ad. Below is a sample
query that uses all of these (note that I've removed actual strings to
protect customer data). The result is fine in terms of speed, but since it's
using the ad_log_ad_date index I'm wondering what the best strategy is to
cover queries that don't specify an ad. Should I have 4 indices, one with
just the start_time (for when no other columns are specified) and the other
three each with the start_time and the three other criteria: channel,
player, and ad? I'm currently experimenting with various options, but since
it takes a couple of hours to create a particular index this is taking a
while.
# explain analyze SELECT ad_log.ad_log_id, channels.name as channel_name,
players.name as player_name, ads.name as ad_name, start_time, end_time,
(data IS NOT NULL) AS has_screenshot FROM channels, players,
players_history, ads, ad_log LEFT OUTER JOIN ad_log_screenshot USING
(ad_log_id) WHERE channel=channels.id AND player=players_history.id AND
players_history.player_instance = players.id AND ad=ads.id AND channels.name
LIKE 'some channel' AND players.name LIKE 'some player' AND ads.name
LIKE 'some ad' AND date(start_time) BETWEEN '2009-01-20' AND
date('2009-01-21') ORDER BY channels.name, players.name, start_time,
ads.name LIMIT 100 OFFSET 100;
QUERY PLAN
--
Limit (cost=7425.26..7425.26 rows=1 width=120) (actual
time=1256.116..1256.202 rows=39 loops=1)
- Sort (cost=7425.26..7425.26 rows=1 width=120) (actual
time=1255.965..1256.068 rows=139 loops=1)
Sort Key: channels.name, players.name, ad_log.start_time, ads.name
Sort Method: quicksort Memory: 35kB
- Nested Loop Left Join (cost=0.01..7425.25 rows=1 width=120)
(actual time=179.086..1255.451 rows=139 loops=1)
- Nested Loop (cost=0.01..7417.06 rows=1 width=88) (actual
time=137.488..1212.531 rows=139 loops=1)
Join Filter: (ad_log.channel = channels.id)
- Nested Loop (cost=0.01..7415.73 rows=1 width=60)
(actual time=120.308..1192.867 rows=139 loops=1)
Join Filter: (players_history.id = ad_log.player)
- Nested Loop (cost=0.00..36.92 rows=1
width=17) (actual time=21.960..23.405 rows=1 loops=1)
Join Filter: (players.id =
players_history.player_instance)
- Seq Scan on players (cost=0.00..11.80
rows=1 width=17) (actual time=5.981..6.083 rows=1 loops=1)
Filter: (name ~~ 'some
player'::text)
- Seq Scan on players_history
(cost=0.00..14.50 rows=850 width=8) (actual time=15.880..16.592 rows=850
loops=1)
- Nested Loop (cost=0.01..7371.03 rows=622
width=51) (actual time=75.161..1156.076 rows=15600 loops=1)
- Seq Scan on ads (cost=0.00..72.79
rows=1 width=27) (actual time=15.776..31.975 rows=1 loops=1)
Filter: (name ~~ 'some ad'::text)
- Index Scan using ad_log_ad_date on
ad_log (cost=0.01..7267.77 rows=2438 width=32) (actual
time=59.375..1095.229 rows=15600 loops=1)
Index Cond: ((ad_log.ad = ads.id) AND
(date(ad_log.start_time) = '2009-01-20'::date) AND (date(ad_log.start_time)
= '2009-01-21'::date))
- Seq Scan on channels (cost=0.00..1.31 rows=1
width=36) (actual time=0.128..0.132 rows=1 loops=139)
Filter: (channels.name ~~ 'some channel'::text)
- Index Scan using ad_log_screenshot_pkey on
ad_log_screenshot (cost=0.00..8.18 rows=1 width=36) (actual
time=0.304..0.304 rows=0 loops=139)
Index Cond: (ad_log.ad_log_id =
Re: [PERFORM] difficulties with time based queries
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 especially 11.3 and 11.5? regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Using IOZone to simulate DB access patterns
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
