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

Re: BUG #5733: Strange planer behaviour with inherited tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Marcus Wirsing" <mw(at)hesotech(dot)de>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5733: Strange planer behaviour with inherited tables
Date: 2010-10-31 14:52:12
Message-ID: 20420.1288536732@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
"Marcus Wirsing" <mw(at)hesotech(dot)de> writes:
> when I execute the following script, the planer always makes a seq. scan
> over all child tables.
> when I remove the min_mv real[] the planer makes an index scan as expected.

I see no bug here.  Adding or removing a column changes the estimated
width of rows, hence the estimated row counts, and that makes some small
differences in the cost estimates.  For empty toy tables like these,
the cost estimates for different scan types are close enough together
that seemingly irrelevant details can change the outcome.

If you've got an actual problem, it's unlikely that discussing trivial
examples like this will help get to the bottom of it.  We'd need to look
at example tables that have realistic statistics.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Dimitri FontaineDate: 2010-10-31 15:32:48
Subject: Re: BUG #5736: 9.0.1 segmentation fault (sig11) during long-lived update
Previous:From: Arturas MazeikaDate: 2010-10-31 01:30:13
Subject: Re: BUG #5735: pg_upgrade thinks that it did not start the old server

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