Re: [PERFORM] Extracting superlatives - SQL design philosophy

2010-02-25 Thread Richard Huxton
On 24/02/10 23:37, Dave Crooke wrote: 1. The city temps table is a toy example, not meant to be realistic :-) You knew that and I guessed it, but it's worth stating these things for people who read the archives a year from now. 2. Yes, my (Java) algorithm is deterministic ... it will

Re: [PERFORM] Extracting superlatives - SQL design philosophy

2010-02-25 Thread Pierre C
-- More explicit select aggregate_using(max(date), city, temp, date) from bar group by city, temp order by city; select city, max(ROW(temp, date)) from bar group by city; Does not work (alas) for lack of a default comparison for record type. Another solution, which works wonders if you've

Re: [PERFORM] Extracting superlatives - SQL design philosophy

2010-02-25 Thread Julien Theulier
Hi all, Just for your information, and this is not related to PG directly: Teradata provides a “qualify” syntax which works as a filtering condition on a windowed function result. This is the only DB allowing this direct filtering on windowed functions, from what I know. So, as an example,

Re: [PERFORM] Extracting superlatives - SQL design philosophy

2010-02-25 Thread Tom Lane
Julien Theulier jul...@squidsolutions.com writes: Teradata provides a “qualify” syntax which works as a filtering condition on a windowed function result. This is the only DB allowing this direct filtering on windowed functions, from what I know. Seems like you could easily translate that into

[PERFORM] dbt2 performance

2010-02-25 Thread Yu-Ju Hong
Hi, I have a couple of questions about dbt2 performance. 1. I tested dbt2+postgresql 8.4.2 on my server, but the NOTPM is around only 320~390 with 10 connections and 30 warehouses. Increasing the number of connections did not improve the throughput? The NOPTM number does not seem very high to

Re: [PERFORM] dbt2 performance

2010-02-25 Thread Greg Smith
Yu-Ju Hong wrote: 2. Moreover, the disk utilization was high and the await time from iostat is around 500 ms. Could disk I/O limit the overall throughput? The server has 2 SATA disks, one for system and postgresql and the other is dedicated to logging (pg_xlog). As far as I understand, modern

Re: [PERFORM] dbt2 performance

2010-02-25 Thread Yu-Ju Hong
Thanks for the reply. On Thu, Feb 25, 2010 at 5:48 PM, Greg Smith g...@2ndquadrant.com wrote: Yu-Ju Hong wrote: 2. Moreover, the disk utilization was high and the await time from iostat is around 500 ms. Could disk I/O limit the overall throughput? The server has 2 SATA disks, one for

Re: [PERFORM] GiST index performance

2010-02-25 Thread Bruce Momjian
Was there every any conclusion on this issue? --- Matthew Wakeling wrote: Revisiting the thread a month back or so, I'm still investigating performance problems with GiST indexes in Postgres. Looking at

Re: [PERFORM] GiST index performance

2010-02-25 Thread Bruce Momjian
Was this corrected? I don't see any commits to seg.c. --- Matthew Wakeling wrote: On Thu, 7 May 2009, Oleg Bartunov wrote: Did you try Guttman quadratic split algorithm ? We also found linear split algorithm for

Re: [PERFORM] No hash join across partitioned tables?

2010-02-25 Thread Bruce Momjian
Did this get addressed? --- Tom Lane wrote: Kris Jurka bo...@ejurka.com writes: The real problem is getting reasonable stats to pass through the partition Append step, so it can make a reasonable estimate of the join

Re: [PERFORM] No hash join across partitioned tables?

2010-02-25 Thread Tom Lane
Bruce Momjian br...@momjian.us writes: Did this get addressed? Partially. There are stats now but autovacuum is not bright about when to update them. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to

[PERFORM] bgwriter, checkpoints, curious (seeing delays)

2010-02-25 Thread Tory M Blue
Okay ladies and gents and the rest of you :) It's time I dig into another issue, and that's a curious 5 second delay on connect, on occasion. Now, I believe the network to be sound and there are zero errors on any servers, no retrans, no runts, nada nada nada. However I will continue to run tests

Re: [PERFORM] bgwriter, checkpoints, curious (seeing delays)

2010-02-25 Thread Tory M Blue
On Thu, Feb 25, 2010 at 10:12 PM, Tory M Blue tmb...@gmail.com wrote: Okay ladies and gents and the rest of you :) It's time I dig into another issue, and that's a curious 5 second delay on connect, on occasion. Now, I believe the network to be sound and there are zero errors on any servers,

Re: [PERFORM] bgwriter, checkpoints, curious (seeing delays)

2010-02-25 Thread Jochen Erwied
Friday, February 26, 2010, 7:20:38 AM you wrote: checkpoint_completion_target (floating point) interesting that it's a .5 second default setting and I'm seeing exactly that .5 second delay. It's not an exact time, but a multiplier to

Re: [PERFORM] bgwriter, checkpoints, curious (seeing delays)

2010-02-25 Thread Devrim GÜNDÜZ
On Thu, 2010-02-25 at 22:12 -0800, Tory M Blue wrote: shared_buffers = 1500MB Some people tend to increase this to 2.2GB(32-bit) or 4-6 GB (64 bit), if needed. Please note that more shared_buffers will lead to more pressure on bgwriter, but it also has lots of benefits, too. work_mem = 100MB

Re: [PERFORM] bgwriter, checkpoints, curious (seeing delays)

2010-02-25 Thread Tory M Blue
2010/2/25 Devrim GÜNDÜZ dev...@gunduz.org: On Thu, 2010-02-25 at 22:12 -0800, Tory M Blue wrote: shared_buffers = 1500MB Some people tend to increase this to 2.2GB(32-bit) or 4-6 GB (64 bit), if needed. Please note that more shared_buffers will lead to more pressure on bgwriter, but it also

Re: [PERFORM] bgwriter, checkpoints, curious (seeing delays)

2010-02-25 Thread Tory M Blue
2010/2/25 Tory M Blue tmb...@gmail.com: 2010/2/25 Devrim GÜNDÜZ dev...@gunduz.org: On Thu, 2010-02-25 at 22:12 -0800, Tory M Blue wrote: shared_buffers = 1500MB Some people tend to increase this to 2.2GB(32-bit) or 4-6 GB (64 bit), if needed. Please note that more shared_buffers will lead to

Re: [PERFORM] bgwriter, checkpoints, curious (seeing delays)

2010-02-25 Thread Devrim GÜNDÜZ
On Thu, 2010-02-25 at 23:01 -0800, Tory M Blue wrote: Checkpoint_timeout is the default and that looks like 5 mins (300 seconds). And is obviously why I have such a discrepancy between time reached and requested. If you have a high load, you may want to start tuning with 15 minutes, and bump