Re: Very slow query

From: Nick Barr <nicky(at)chuckie(dot)co(dot)uk>
To: Rory Campbell-Lange <rory(at)campbell-lange(dot)net>
Cc: Postgresql General List <pgsql-general(at)postgresql(dot)org>
Subject: Re: Very slow query
Date: 2004-05-10 23:09:23
Message-ID: 40A00BA3.8050908@chuckie.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

[snip]
Rory Campbell-Lange wrote:
>>
>>
>>SELECT DISTINCT
>> b.n_id as id,
>> b.n_type,
>> CASE b.n_type WHEN 0 THEN 'personal'
>> WHEN 1 THEN 'private'
>> WHEN 2 THEN 'blog'
>> ELSE 'public'
>> END as type,
>> b.t_name as title
>> FROM
>> boards b, people p, objects o
>> WHERE
>> b.b_hidden = 'f'
>> AND
>> (
>> b.n_type = 3
>> OR
>> b.n_creator = 71
>> OR
>> ( b.n_id = o.n_board_id
>> AND
>> o.n_creator = 71
>> AND
>> o.n_joined > 0
>> )
>> )
>> ORDER BY
>> b.n_type, b.n_id ASC, b.t_name;
>>

You don't seem to be joining the people table to the boards or objects
table. In fact the people table is never referenced anywhere but the
FROM clause. This might be why it is not running so well. People seems
to be referenced by both boards and objects, so does there need to be a
join between all 3 tables?

[snip]

>> "$1" FOREIGN KEY (n_creator) REFERENCES people(n_id) ON UPDATE CASCADE ON DELETE CASCADE

[snip]

>> "$1" FOREIGN KEY (n_creator) REFERENCES people(n_id) ON UPDATE CASCADE ON DELETE CASCADE

It is this "missing" join which seems to cause 158254 rows to appear in
this nested loop, when PG only reckons it is going to see 2738 rows

>> -> Nested Loop (cost=3442.79..3520.93 rows=2738 width=18) (actual time=0.244..1052.180 rows=158254 loops=1)

I cant remember what the correct term is, but basically all rows from
the seq scan combines with all rows from the materialize, which is what
is causing the 150,000 odd rows to appear (is that called a cross
product anyone?)

i.e

67 rows from the seq x 2362 rows from the materialize = 158254 output
rows for the nested loop to chug through.

>> -> Seq Scan on people p (cost=0.00..2.67 rows=67 width=0) (actual time=0.012..0.709 rows=67 loops=1)
>> -> Materialize (cost=3442.79..3443.20 rows=41 width=18) (actual time=0.005..6.528 rows=2362 loops=67)

I reckon fix the unconstrained join and your query might run a little
faster.

>> -> Nested Loop (cost=3.27..3442.79 rows=41
width=18) (actual time=0.216..273.709 rows=2362 loops=1)

The estimate for this nested loop seems a little off, note the
guesstimate in the first set of brackets of 41, and compare with the
actual result in the second set of 2362. Have you vacuum analyzed recently?

HTH

Nick

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2004-05-10 23:18:09 Re: Interpreting vacuum verbosity
Previous Message Ivan Sergio Borgonovo 2004-05-10 22:58:55 Re: nested elseif woes