Re: Queries joining views

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alban Hertroys <alban(at)magproductions(dot)nl>
Cc: DelGurth <delgurth(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Queries joining views
Date: 2006-08-22 14:48:07
Message-ID: 3222.1156258087@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Alban Hertroys <alban(at)magproductions(dot)nl> writes:
> tablename | mm_product_table
> attname | number
> histogram_bounds | {2930,3244,3558,3872,4186,4500,4814,5128,5442,5756,6070}

> tablename | mm_insrel_table
> attname | snumber
> histogram_bounds |
> {135,3768,4780,14822,57048,92958,125442,158954,433002,502836,610034}

Hmm ... if I'm not still confused, these are the two columns being
mergejoined in your slow query (would you double-check that?).
But the numbers don't seem to add up. Given those stats the estimate
should be that something over 20% of the mm_insrel_table has to be
scanned to complete the join (since 6070 falls into the third decile
of the other histogram). But we saw from Alban's original post that
the planner must be estimating well under 10% of the table needs to
be scanned. Either we're still confused about which columns are being
joined, or there's some weird bug in the computation.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Vance Maverick 2006-08-22 14:49:26 Re: UUID as primary key
Previous Message Michael Fuhr 2006-08-22 13:59:35 Re: trigger help

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-08-22 15:06:09 Re: seahorse again failing
Previous Message Martijn van Oosterhout 2006-08-22 14:44:28 Re: seahorse again failing