On Wed, 27 Aug 2003, mike wrote:
> Hi,
> On Tue, 26 Aug 2003, Stephan Szabo wrote:
> ...
> > But does it change the amount of time the query actually takes to run?
> > seqscans are not always slower nor are they necessarily the actual problem
> > here. The problem seems to be choosing a group aggregate + sort which is
> > taking alot of time, if you look at the real time on the steps below that
> > it's approximately the same for seqscan or index scan.
>
> Ok, with plenty of sort_mem (327680) the seqscan seems to be faster.
Eek. That's really big. Was that the swap over point, or was that just
an arbitrary large value. Basically it looks like the difference really
is whether it uses the hash aggregate on the first and third query or not.
The question is figuring out at what point that switches over, and how bad
it is to use that much ram for this query (btw: what does say top/free/ps
say while the query is running for large sort_mem vs small sort_mem)?
