From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "'herve(at)elma(dot)fr'" <herve(at)elma(dot)fr>, pgsql-general(at)postgresql(dot)org |
Subject: | RE: Really SLOW using GROUP BY ...!? |
Date: | 2000-11-08 21:30:11 |
Message-ID: | 8F4C99C66D04D4118F580090272A7A234D3160@sectorbase1.sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> I beg your pardon?
Get it - I didn't know about enable_seqscan -:)
> Unfortunately neither of these plans is likely to be especially speedy
> on ~3 million rows. The index scan will just thrash the disk, unless
> the table has been clustered recently --- and given the
> deficiencies of our CLUSTER implementation, I'd hesitate to recommend
> using it.
Easy to try - why don't do.
> I have a personal TODO item to see about implementing group +
> aggregate with a hash table of active aggregate values, per a
> suggestion recently from devik(at)cdi(dot)cz(dot) That would allow this
> query to be done with a sequential scan and no sort, which is
> probably what Oracle is doing. Won't happen for 7.1 though ...
Well, definitely good approach. But for the moment increasing
sort memory is only hope and it should help.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Hervé Piedvache | 2000-11-08 21:43:33 | Re: Really SLOW using GROUP BY ...!? |
Previous Message | Bruce Momjian | 2000-11-08 21:27:34 | Re: VACUUM AND VACUUM ANALYSE |