| From: | "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk> |
|---|---|
| To: | Kathy Zhu <Kathy(dot)Zhu(at)Sun(dot)COM> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: group by |
| Date: | 2003-10-03 22:52:31 |
| Message-ID: | Pine.LNX.4.21.0310032349300.18083-100000@ponder.fairway2k.co.uk |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Fri, 3 Oct 2003, Kathy Zhu wrote:
> Hi,
>
> I notices a weird thing here.
>
> version 7.2.1
> on Solaris
>
> table "test", has a field "state".
> There are 4 "state" values, 1, 2, 3, 4.
>
> select count(*) from test group by state;
> took 11500 msec
>
> but
>
> select count(*) from test where state = 1;
> select count(*) from test where state = 2;
> select count(*) from test where state = 3;
> select count(*) from test where state = 4;
> total took 626 msec
>
> Why ??
First thought was caching: the disk blocks are cached in memory after the first
qery so all the others just fetch from there.
Second thought: well I haven't really had it but indexes and sorting is sort of
sloshing around in my mind. Not sure how that applies to here since I can't
remember if the first would require the sort step having retrieved all the
tuples and the others would just use the index pages.
It is Friday though.
--
Nigel J. Andrews
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dennis Gearon | 2003-10-03 22:53:02 | Re: group by |
| Previous Message | Kathy Zhu | 2003-10-03 22:30:14 | group by |