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 [EMAIL PROTECTED] 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é
