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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-bugs by date

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