Skip site navigation (1) Skip section navigation (2)

Re: multi-layered view join performance oddities

From: "Steinar H(dot) Gunderson" <sgunderson(at)bigfoot(dot)com>
To: Svenne Krap <svenne(at)krap(dot)dk>
Cc: PgSQL Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: multi-layered view join performance oddities
Date: 2005-10-30 17:44:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Sun, Oct 30, 2005 at 06:16:04PM +0100, Svenne Krap wrote:
>  Nested Loop  (cost=223.09..338.61 rows=1 width=174) (actual time=20.213..721.361 rows=2250 loops=1)
>    Join Filter: (("outer".dataset_id = "inner".dataset_id) AND ("outer".nb_property_type_id = "inner".nb_property_type_id))
>    ->  Hash Join  (cost=58.04..164.26 rows=1 width=150) (actual time=5.510..22.088 rows=2250 loops=1)

There's horrible misestimation here. It expects one row and thus starts a
nested loop, but gets 2250. No wonder it's slow :-)

The misestimation can be traced all the way down here:

>          Hash Cond: ("outer".institut = "inner".id)
>          ->  Hash Join  (cost=56.88..163.00 rows=16 width=137) (actual time=5.473..19.165 rows=2250 loops=1)
>                Hash Cond: ("outer".dataset_id = "inner".id)
>                ->  Hash Join  (cost=55.48..160.95 rows=99 width=101) (actual time=5.412..16.264 rows=2250 loops=1)

where the planner misestimates the selectivity of your join (it estimates 99
rows, and there are 2250).

I've had problems joining with Append nodes in the past, and solved the
problem by moving the UNION ALL a bit out, but I'm not sure if it's a very
good general solution, or a solution to your problems here.

If all else fails, you could "set enable_nestloop=false", but that is not a
good idea in the long run, I'd guess -- it's much better to make sure the
planner has good estimates and let it do the correct decisions from there.

/* Steinar */

In response to


pgsql-performance by date

Next:From: Tom LaneDate: 2005-10-30 18:27:01
Subject: Re: multi-layered view join performance oddities
Previous:From: Svenne KrapDate: 2005-10-30 17:16:04
Subject: multi-layered view join performance oddities

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group