Quoting Dennis Sacks <[EMAIL PROTECTED]>:
> Bruno Wolff III wrote:
> >On Tue, Jan 25, 2005 at 21:21:08 -0700,
> > Dennis Sacks <[EMAIL PROTECTED]> wrote:
> >>One of the things you'll want to do regularly is run a "vacuum analyze".
> >>You can read up on this in the postgresql docs. This is essent
o:[EMAIL PROTECTED]
Sent: Wednesday, January 26, 2005 5:16 PM
To: Joel Fradkin
Cc: pgsql-sql@postgresql.org
Subject: Re: [SQL] same question little different test MSSQL vrs Postgres
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We've done some pretty extensive benchmarking and load testing on a
cou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We've done some pretty extensive benchmarking and load testing on a
couple of platforms including the Xeon and Opteron. You may have already
bought that Dell box, but I'll say it anyway. Xeon quad processors are a
terrible platform for postgres. Trying
Bruno Wolff III wrote:
On Tue, Jan 25, 2005 at 21:21:08 -0700,
Dennis Sacks <[EMAIL PROTECTED]> wrote:
One of the things you'll want to do regularly is run a "vacuum analyze".
You can read up on this in the postgresql docs. This is essential to the
indexes being used properly. At a bare minim
On Tue, Jan 25, 2005 at 21:21:08 -0700,
Dennis Sacks <[EMAIL PROTECTED]> wrote:
>
> One of the things you'll want to do regularly is run a "vacuum analyze".
> You can read up on this in the postgresql docs. This is essential to the
> indexes being used properly. At a bare minimum, after you im
Joel Fradkin wrote:
Thank you I will look at that info.
I did do an EXPLAIN ANALYSE on the view and could see it was doing the seq
scan on 3 fields, so I did an index for the three fields and it then chose
an index scan and ran in 27 seconds.
I also did adjust my defaults to much smaller numbers on
Re: [SQL] same question little different test MSSQL vrs Postgres
"Joel Fradkin" <[EMAIL PROTECTED]> writes:
> I tried the SET ENABLE_SEQSCAN=FALSE;
> And the result took 29 secs instead of 117.
>
> After playing around with the cache and buffers etc I see I am no longe
Joel Fradkin wrote:
The postgres is running on Linux Fedora core 3 (production will be redhat on
Dell 4 proc 8 gig box).
My client pgadminIII is running on XP.
Sorry I was not clearer on this.
Ah! you're the gent who had the problems with SE-Linux on Fedora 3.
Sorry - should have made the connecti
"Joel Fradkin" <[EMAIL PROTECTED]> writes:
> I tried the SET ENABLE_SEQSCAN=FALSE;
> And the result took 29 secs instead of 117.
>
> After playing around with the cache and buffers etc I see I am no longer
> doing any swapping (not sure how I got the 100 sec response might have been
> shared buff
radkin
Cc: [EMAIL PROTECTED]; pgsql-sql@postgresql.org
Subject: Re: [SQL] same question little different test MSSQL vrs Postgres
Joel Fradkin wrote:
> Well last evening (did not try it this morning) it was taking the extra
> time.
>
> I have made some adjustments to the config file per a f
"Joel Fradkin" <[EMAIL PROTECTED]> writes:
> QUERY PLAN
> "Seq Scan on tblcase (cost=0.00..30066.21 rows=37401 width=996) (actual
> time=0.344..962.260 rows=22636 loops=1)"
> " Filter: ((clientnum)::text = 'SAKS'::text)"
> "Total runtime: 1034.434 ms"
Well that says it only took 1s. So it seems
ents.
-Original Message-
From: Richard Huxton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 26, 2005 10:21 AM
To: Joel Fradkin
Cc: [EMAIL PROTECTED]; pgsql-sql@postgresql.org
Subject: Re: [SQL] same question little different test MSSQL vrs Postgres
Joel Fradkin wrote:
> Well last eveni
Well last evening (did not try it this morning) it was taking the extra
time.
I have made some adjustments to the config file per a few web sites that you
all recommended my looking at.
It is now using 137 of 756 meg avail.
it is now taking 8 secs to return 22,000 rows (using pgadminIII in a sql
Joel Fradkin wrote:
Well last evening (did not try it this morning) it was taking the extra
time.
I have made some adjustments to the config file per a few web sites that you
all recommended my looking at.
The crucial one I'd say is the performance guide at:
http://www.varlena.com/varlena/General
Joel Fradkin wrote:
QUERY PLAN
"Seq Scan on tblcase (cost=0.00..30066.21 rows=37401 width=996) (actual
time=0.344..962.260 rows=22636 loops=1)"
" Filter: ((clientnum)::text = 'SAKS'::text)"
"Total runtime: 1034.434 ms"
That's only 1 second - to return 22,636 rows. Not 27 seconds, as in the
origi
Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 26, 2005 1:27 AM
To: Joel Fradkin
Cc: pgsql-sql@postgresql.org
Subject: Re: [SQL] same question little different test MSSQL vrs Postgres
"Joel Fradkin" <[EMAIL PROTECTED]> writes:
> I a
"Joel Fradkin" <[EMAIL PROTECTED]> writes:
> I also tried a simple select * from tblcase where clientum = 'SAKS'
Try:
explain analyze select * from tblcase where clientum = 'SAKS'
Send the output.
--
greg
---(end of broadcast)---
TIP 4: Don't
Joel Fradkin wrote:
I also tried a simple
select * from tblcase where clientum =
‘SAKS’
On both MSSQL and
Postgres.
MSSQL was 3 secs,
Postgres was 27 secs.
There is a key for
clientnum, but it appeared on both
systems (identical Dell Desktops Postgres is running Linux M
I also tried a simple select * from tblcase where clientum =
‘SAKS’
On both MSSQL and Postgres.
MSSQL was 3 secs, Postgres was 27 secs.
There is a key for clientnum, but it appeared on both
systems (identical Dell Desktops Postgres is running Linux MSSQL is XP) it did
not do a indexed
19 matches
Mail list logo
