From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Joel Fradkin" <jfradkin(at)wazagua(dot)com> |
Cc: | "'Michael Fuhr'" <mike(at)fuhr(dot)org>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: MSSQL versus Postgres timing |
Date: | 2005-02-01 21:53:23 |
Message-ID: | 19308.1107294803@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
"Joel Fradkin" <jfradkin(at)wazagua(dot)com> writes:
> " -> Sort (cost=38119.24..38333.26 rows=85611 width=52) (actual time=20667.645..21031.627 rows=99139 loops=1)"
> " Sort Key: (a.clientnum)::text, a.jobtitleid"
> " -> Seq Scan on tblassociate a (cost=0.00..31105.34 rows=85611 width=52) (actual time=14.768..16024.395 rows=99139 loops=1)"
> " Filter: ((clientnum)::text = 'SAKS'::text)"
The sort steps seem slower than they ought to be. I suspect you ought
to raise sort_mem ... try 10MB instead of 1MB. Also, if you are running
in a locale other than C and don't have a good reason for doing so, it
would be worth trying C locale instead.
The results with enable_seqscan off also suggest that random_page_cost
may be too high for your environment.
BTW, the schema you posted does not match these plans --- there are
indexes referenced in the plans that do not appear in the schema.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Fradkin | 2005-02-01 22:09:13 | Re: MSSQL versus Postgres timing |
Previous Message | PFC | 2005-02-01 21:47:19 | Re: MSSQL versus Postgres timing |