Hi,
I should state that I use 7.4beta1 under FreeBSD -current.

On Thu, 21 Aug 2003, mike wrote:

Bye/2
---
Michael Reifenberger, Business Unit Manager SAP-Basis, Plaut Consulting
Comp: Michael.Reifenberger (AT) plaut (DOT) de | Priv: Michael (AT) Reifenberger (DOT) com
http://www.plaut.de | http://www.Reifenberger.com


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

On Thu, 21 Aug 2003, mike wrote:

It looks like the row estimates changed to say that a large % of the rows
match the condition. Is that true? In any case, what does EXPLAIN
ANALYZE rather than EXPLAIN say for the various queries?


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

On Mon, 25 Aug 2003, mike wrote:

There are two things that jump out at me, the first is that the group
aggregate estimates on the after are way higher than reality and that it
looks to me that the sort before the group aggregate is taking longer than
expected. What do you have sort_mem set to since that will affect whether
sorts are in memory and I believe whether it thinks it can use a hash
aggregate on that nubmer of rows.





---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

On Tue, 26 Aug 2003, mike 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.


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

On Mon, 25 Aug 2003, Stephan Szabo wrote:

sort_men was at the default.
But setting it to 10240 doesn't seem to change the seqscan on flows.


Bye/2
---
Michael Reifenberger, Business Unit Manager SAP-Basis, Plaut Consulting
Comp: Michael.Reifenberger (AT) plaut (DOT) de | Priv: Michael (AT) Reifenberger (DOT) com
http://www.plaut.de | http://www.Reifenberger.com


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

On Wed, 27 Aug 2003, mike wrote:

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)?



---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend