e correct that there's poor quality junk out there. I was not
> talking about it, only reasonable quality components.
>
> Ron
>
>
> -Original Message-
> From: Kurt De Grave <[EMAIL PROTECTED]>
> Sent: Nov 10, 2005 5:40 AM
> To: Ron Peacetree <[EMAIL PROT
---Original Message-
From: Kurt De Grave <[EMAIL PROTECTED]>
Sent: Nov 10, 2005 5:40 AM
To: Ron Peacetree <[EMAIL PROTECTED]>
Cc: Charlie Savage <[EMAIL PROTECTED]>, pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Sort performance on large tables
On Wed, 9 Nov 2005,
DB server. It makes all kinds of problems just not exist.
Ron
-Original Message-
From: Simon Riggs <[EMAIL PROTECTED]>
Sent: Nov 9, 2005 4:35 AM
To: Charlie Savage <[EMAIL PROTECTED]>, Luke Lonergan <[EMAIL PROTECTED]>
Cc: pgsql-performance@postgresql.org
Subject: Re: [PE
Hi Simon,
Thanks for the response Simon.
PostgreSQL can do HashAggregates as well as GroupAggregates, just like
Oracle. HashAggs avoid the sort phase, so would improve performance
considerably. The difference in performance you are getting is because
of the different plan used. Did you specific
On Tue, 2005-11-08 at 00:05 -0700, Charlie Savage wrote:
> Setup: Dell Dimension 3000, Suse 10, 1GB ram, PostgreSQL 8.1 RC 1 with
> I want to extract data out of the file, with the most important values
> being stored in a column called tlid. The tlid field is an integer, and
> the values are
I solved it in my
application by the following type of query.
Assumes of course that you have an index on tlid.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Charlie Savage
Sent: Tuesday, November 08, 2005 2:05 AM
To: pgsql-performance
I'd set up a trigger to maintain summary tables perhaps...
Chris
Charlie Savage wrote:
Thanks everyone for the feedback.
I tried increasing work_mem:
set work_mem to 30;
select tlid, min(ogc_fid)
from completechain
group by tld;
The results are:
"GroupAggregate (cost=9041602.80..1000
Its an int4.
Charlie
Tom Lane wrote:
Charlie Savage <[EMAIL PROTECTED]> writes:
Thus the time decreased from 8486 seconds to 5279 seconds - which is a
nice improvement. However, that still leaves postgresql about 9 times
slower.
BTW, what data type are you sorting, exactly? If it's a stri
Charlie Savage <[EMAIL PROTECTED]> writes:
> Thus the time decreased from 8486 seconds to 5279 seconds - which is a
> nice improvement. However, that still leaves postgresql about 9 times
> slower.
BTW, what data type are you sorting, exactly? If it's a string type,
what is your LC_COLLATE set
Thanks everyone for the feedback.
I tried increasing work_mem:
set work_mem to 30;
select tlid, min(ogc_fid)
from completechain
group by tld;
The results are:
"GroupAggregate (cost=9041602.80..10003036.88 rows=48071704 width=8)
(actual time=4371749.523..5106162.256 rows=47599910 loops=1)
On Tue, 8 Nov 2005, Luke Lonergan wrote:
> Stephan,
>
> On 11/8/05 9:38 AM, "Stephan Szabo" <[EMAIL PROTECTED]> wrote:
>
> >> >
> >> > Just as we find with a similar comparison (with a "popular commercial,
> >> > proprietary database" :-) Though some might suggest you increase
> >> > work_mem or
Title: Re: [PERFORM] Sort performance on large tables
Stephan,
On 11/8/05 9:38 AM, "Stephan Szabo" <[EMAIL PROTECTED]> wrote:
>
> Just as we find with a similar comparison (with a "popular commercial,
> proprietary database" :-) Though some might sugge
On Tue, 8 Nov 2005, Luke Lonergan wrote:
> > SELECT tlid, min(ogc_fid)
> > FROM completechain
> > GROUP BY tlid
> > ORDER BY tlid;
> >
> > Even with this, it was more than a magnitude faster than Postgresql.
> > Which makes me think I have somehow misconfigured postgresql
> > (see the relevant par
have an index on tlid.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Charlie Savage
> Sent: Tuesday, November 08, 2005 2:05 AM
> To: pgsql-performance@postgresql.org
> Subject: [PERFORM] Sort performance on large tables
>
Charlie,
> Should I expect results like this? I realize that the
> computer is quite low-end and is very IO bound for this
> query, but I'm still surprised that the sort operation takes so long.
It's the sort performance of Postgres that's your problem.
> Out of curiosity, I setup an Oracle
Charlie Savage wrote:
Hi everyone,
I have a question about the performance of sort.
Note it takes over 10 times longer to do the sort than the full
sequential scan.
Should I expect results like this? I realize that the computer is quite
low-end and is very IO bound for this query, but I'm
Hi everyone,
I have a question about the performance of sort.
Setup: Dell Dimension 3000, Suse 10, 1GB ram, PostgreSQL 8.1 RC 1 with
PostGIS, 1 built-in 80 GB IDE drive, 1 SATA Seagate 400GB drive. The
IDE drive has the OS and the WAL files, the SATA drive the database.
From hdparm the max I
17 matches
Mail list logo
