From: | Markus Schaber <schabios(at)logi-track(dot)com> |
---|---|
To: | Stephen Crowley <stephen(dot)crowley(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Large # of rows in query extremely slow, not using |
Date: | 2004-09-14 16:43:58 |
Message-ID: | 20040914184358.08e271fe@kingfisher.intern.logi-track.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi, Stephen,
On Mon, 13 Sep 2004 19:51:22 -0500
Stephen Crowley <stephen(dot)crowley(at)gmail(dot)com> wrote:
> Does postgres cache the entire result set before it begins returning
> data to the client?
>
> I have a table with ~8 million rows and I am executing a query which
> should return about ~800,000 rows. The problem is that as soon as I
> execute the query it absolutely kills my machine and begins swapping
> for 5 or 6 minutes before it begins returning results. Is postgres
> trying to load the whole query into memory before returning anything?
> Also, why would it choose not to use the index? It is properly
> estimating the # of rows returned. If I set enable_seqscan to off it
> is just as slow.
As you get about 10% of all rows in the table, the query will hit every
page of the table.
Maybe it helps to CLUSTER the table using the index on your query
parameters, and then set enable_seqscan to off.
But beware, that you have to re-CLUSTER after modifications.
HTH,
Markus
--
markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 zürich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios(at)logi-track(dot)com | www.logi-track.com
From | Date | Subject | |
---|---|---|---|
Next Message | Vivek Khera | 2004-09-14 17:28:59 | Re: disk performance benchmarks |
Previous Message | Harald Lau (Sector-X) | 2004-09-14 15:20:43 | Re: Data Warehouse Reevaluation - MySQL vs Postgres -- merge tables |