Re: Dead Lock problem with 8.1.3 - Mailing list pgsql-general

From Tom Lane
Subject Re: Dead Lock problem with 8.1.3
Date
Msg-id 27038.1159463542@sss.pgh.pa.us
Whole thread Raw
In response to Re: Dead Lock problem with 8.1.3  (Kai Hessing <kai.hessing@hobsons.de>)
Responses Re: Dead Lock problem with 8.1.3  (Kai Hessing <kai.hessing@hobsons.de>)
List pgsql-general
Kai Hessing <kai.hessing@hobsons.de> writes:
> PostgreSQL 8.1.4 (The one which is taking... a very long time...)

>         Filter: (NOT (subplan))
>         SubPlan
>           ->  Materialize  (cost=7751.81..8497.94 rows=53613 width=4)

> PostgreSQL 8.0.8 (The one which takes only a few seconds... on a much
> slower system...)

>               Filter: (NOT (hashed subplan))
>               SubPlan
>                 ->  Seq Scan on stud_vera  (cost=0.00..7424.24 rows=1461
> width=4)
>                       Filter: (veraid = 2)

I bet the problem is that you're not getting a hashed subplan in 8.1.
What do you have work_mem set to on the two systems?  The fact that the
rowcount estimate for the subplan is much larger may be causing the
change, too.  Why is that --- perhaps you haven't ANALYZEd stud_vera
recently on one system or the other?  How many rows will really come out
of the sub-select (ie, what's "select count(*) from stud_vera
where veraid = 2")?

            regards, tom lane

pgsql-general by date:

Previous
From: Kai Hessing
Date:
Subject: Re: Dead Lock problem with 8.1.3
Next
From: Lexington Luthor
Date:
Subject: Re: Definition of return types for own functions?