Hi,
I try it and it doesn't resolve the problem:(
So, now what? To leave it that way for this query or There must be
permanent solution because if other queries behave like that?
Kaloyan Iliev
Tom Lane wrote:
Kaloyan Iliev Iliev <[EMAIL PROTECTED]> writes:
Will ANALYZE res
Kaloyan Iliev Iliev <[EMAIL PROTECTED]> writes:
> Will ANALYZE resove this?
Try it and find out.
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
Tom Lane wrote:
I wouldn't recommend turning off hashagg as a permanent solution, it
was just a quickie to verify my suspicion of where the memory was going.
Hi,
How to understant the upper sentence? I shouldn't turn "hashagg" off
permanently for this query or for the entire database. For now I
Kaloyan Iliev Iliev <[EMAIL PROTECTED]> writes:
> It worked. I have read in the docs what this "enable_hashagg" do, but I
> couldn't understand it. What does it change?
Your original 7.4 query plan has several HashAgg steps in it, which are
doing aggregate/GROUP BY operations. The planner thinks
Hi,
I am asking the prev. question because there is no change in the query
plan (as far as I see) but the mem usage decreases from 258M to 16M.
Kaloyan Iliev
Tom Lane wrote:
Kaloyan Iliev Iliev <[EMAIL PROTECTED]> writes:
I have the following problem. A week ago we've migrated f
Thanks,
It worked. I have read in the docs what this "enable_hashagg" do, but I
couldn't understand it. What does it change?
From the Doc:
---
enable_hashagg (boolean)
Enables or disables the query planner's use of hashed aggregation
plan types. The default is on. This is used for debug
Kaloyan Iliev Iliev <[EMAIL PROTECTED]> writes:
> I have the following problem. A week ago we've migrated from PGv7.2.3 to
> 7.4.6. There were a lot of things in the apps to chenge but we made
> them. But one query doesn't want to run. In the old PGv7.2.3 it passes
> for 10 min. In the new one i
