From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
---|---|
To: | Michael Rudolph <MuK(dot)Rudolph(at)t-online(dot)de> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "'Hiroshi Inoue'" <Inoue(at)tpf(dot)co(dot)jp>, "'lockhart(at)fourpalms(dot)org'" <lockhart(at)fourpalms(dot)org> |
Subject: | AW: Re: Slow Performance in PostgreSQL |
Date: | 2001-07-26 07:18:36 |
Message-ID: | 11C1E6749A55D411A9670001FA6879633683A1@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > There is one table, let's
> > say table1, with about 11.0000 rows. On doing a "select distinct var1
> > from table1" via ODBC-Driver, I had to wait about 15 sec for the result.
1. I assume following index exists:
create index table1_x0 on table1 (var1);
"select distinct" when executed through a btree index could benefit from
an optimization as follows:
for each "key" that is already in a sorted list output skip the heap tuple
lookup, since for a duplicate it is not necessary to know the tx status,
not sure if that is implementable though.
(PostreSQL needs to look up the tx status in the table for each key in index)
The performance difference is unfortunately to be expected, since Centura can
probably do the distinct by only looking at the index.
You could try to normalize your schema (pull those values out into an extra table)
if you need such "distinct" queries to be fast.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Zudi Iswanto | 2001-07-26 09:55:14 | |
Previous Message | Thomas Lockhart | 2001-07-26 04:45:50 | Re: Slow Performance in PostgreSQL |