| From: | "Rainer Spittel" <rainer(dot)spittel(at)terralink(dot)co(dot)nz> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: performance on selecting a row in large tables |
| Date: | 2008-02-04 21:24:11 |
| Message-ID: | 12B8F225666F99489CEFA8B3F261540CFAAE11@geneva.local.terralink |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Hi Tom,
You are right, this query is not the right approach for performance
testing. I thought that this will give an indication about the
performance of a select statement on that table.
One of those slow queries are running on col02 which has a btree
index. But I use the 'in' expression to get a set of matching rows:
select * from table where col02 in ('...',[...],'...')
This query gets sometimes really slow, I guess it depends on the size
of the set used by 'in'.
Would the query perform better when I cluster the index on col02 and
force to order the set for the in clause?
Is there a way to disable the caching for testing? Once I ran the
query, the result set seems to be cached and the second run of the query
is fast. This makes a testing a little difficult ;-)
regards.
Rainer
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-02-04 21:43:20 | Re: performance on selecting a row in large tables |
| Previous Message | Tino Schwarze | 2008-02-04 21:20:50 | Re: performance on selecting a row in large tables |