Re: [PERFORM] max() versus order/limit (WAS: High update

2007-01-14 Thread Luke Lonergan
Adam, This optimization would require teaching the planner to use an index for MAX/MIN when available. It seems like an OK thing to do to me. - Luke > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Adam Rich > Sent: Sunday, January 14, 2007 8:52 P

Re: [PERFORM] max() versus order/limit (WAS: High update activity, PostgreSQL vs BigDBMS)

2007-01-14 Thread Adam Rich
Did anybody get a chance to look at this? Is it expected behavior? Everyone seemed so incredulous, I hoped maybe this exposed a bug that would be fixed in a near release. -Original Message- From: Adam Rich [mailto:[EMAIL PROTECTED] Sent: Sunday, January 07, 2007 11:53 PM To: 'Joshua D.

Re: [PERFORM] Large table performance

2007-01-14 Thread Luke Lonergan
Mark, Note that selecting an index column means that Postgres fetches the whole rows from disk. I think your performance problem is either: 1) slow disk or 2) index access of distributed data. If it¹s (1), there are plenty of references from this list on how to check for that and fix it. If it¹

Re: [PERFORM] Large table performance

2007-01-14 Thread Luke Lonergan
Mark, This behavior likely depends on how the data is loaded into the DBMS. If the records you are fetching are distributed widely among the 3M records on disk, then On 1/12/07 4:31 PM, "Mark Dobbrow" <[EMAIL PROTECTED]> wrote: > Hello - > > I have a fairly large table (3 million records),

Re: [PERFORM] Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?)

2007-01-14 Thread Dave Cramer
On 14-Jan-07, at 10:34 AM, Rolf Østvik (HA/EXA) wrote: Computer: Dell PowerEdge 2950 openSUSE Linux 10.1 Intel(R) Xeon 3.00GHz 4GB memory xfs filesystem on SAS disks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf

Re: [PERFORM] Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?)

2007-01-14 Thread Dave Dutcher
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Rolf Østvik (HA/EXA) Have you tried "set enable_sort=off" with 8.1.2? I'm not sure if that will change anything because it has to do at least one sort. Its just a lots faster to do a hashagg + sma

Re: [PERFORM] Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?)

2007-01-14 Thread HA/EXA
Computer: Dell PowerEdge 2950 openSUSE Linux 10.1 Intel(R) Xeon 3.00GHz 4GB memory xfs filesystem on SAS disks > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Rolf Østvik (HA/EXA) > Sent: Sunday, January 1

Re: [PERFORM]

2007-01-14 Thread Dave Cramer
On 14-Jan-07, at 7:31 AM, Rolf Østvik (HA/EXA) wrote: 1234567890123456789012345678901234567890123456789012345678901234567890 1234567890 00112233445566 77 I have been trying to change a many parameters on server versions 7.4.15, 8

[PERFORM] Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?)

2007-01-14 Thread HA/EXA
(now with a more sensible subject) I have been trying to change a many parameters on server versions 7.4.15, 8.1.4, 8.2.0 and 8.2.1. I still hope a have managed to keep my head straigth and that i do not present to much faulty information. The cost estimates generated by the different server vers

[PERFORM]

2007-01-14 Thread HA/EXA
12345678901234567890123456789012345678901234567890123456789012345678901234567890 0011223344556677 I have been trying to change a many parameters on server versions 7.4.15, 8.1.4, 8.2.0 and 8.2.1. I still hope a have managed to keep my

Re: [PERFORM] Large table performance

2007-01-14 Thread Shoaib Mir
Depending on the available memory try increasing the shared buffers and work_mem and see if that changes the query execution time. Also make sure you have proper indices created and also if possible try doing partitions for the table. Once you post the EXPLAIN ANALYZE output that will certainly h