Chris Kratz skrev:
Hello Everyone,
I'm struggling to get postgres to run a particular query quickly. It
seems that very early on, the planner seems to mis-estimate the
number of rows returned by a join which causes it to assume that
there is only 1 row as it goes up the tree. It then
On Wednesday 17 October 2007 20:23, Tom Lane wrote:
Chris Kratz [EMAIL PROTECTED] writes:
On Wednesday 17 October 2007 14:49, Tom Lane wrote:
Evidently it's not realizing that every row of par will have a join
partner, but why not? I suppose a.activityid is unique, and in most
cases
Hello Everyone,
I'm struggling to get postgres to run a particular query quickly. It seems
that very early on, the planner seems to mis-estimate the number of rows
returned by a join which causes it to assume that there is only 1 row as it
goes up the tree. It then picks a nested loop join
Chris Kratz [EMAIL PROTECTED] writes:
I'm struggling to get postgres to run a particular query quickly.
The key problem seems to be the join size misestimate here:
- Hash Join (cost=45.92..1251.07 rows=21 width=8) (actual
time=0.948..10.439 rows=1199 loops=1)
On Wednesday 17 October 2007 14:49, Tom Lane wrote:
Chris Kratz [EMAIL PROTECTED] writes:
I'm struggling to get postgres to run a particular query quickly.
The key problem seems to be the join size misestimate here:
- Hash Join (cost=45.92..1251.07 rows=21 width=8)
Chris Kratz [EMAIL PROTECTED] writes:
On Wednesday 17 October 2007 14:49, Tom Lane wrote:
Evidently it's not realizing that every row of par will have a join
partner, but why not? I suppose a.activityid is unique, and in most
cases that I've seen the code seems to get that case right.
