| 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: | Whole Thread | Raw Message | 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 |