Hi Tom,
Tom Lane a écrit :
>
> 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.
Sorry but I don't understand ... you tell me to not use the CLUSTER
implementation ?
What is the risk of using it ?
What can I do to solve my group by slower trouble ? Just waiting you
implement the option you talk after... ?
Group by is a classical SQL command, what can I do to circumvent this
problem ? Other SQL method ?
Thanks for your reply,
> 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@cdi.cz. 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 ...
>
> regards, tom lane
Regards,
--
Hervé
