Re: Hash Index Build Patch

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tom Raney <twraney(at)comcast(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Hash Index Build Patch
Date: 2007-09-27 08:09:17
Message-ID: 1190880557.4194.22.camel@ebony.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On Wed, 2007-09-26 at 16:06 -0400, Tom Lane wrote:
> Tom Raney <twraney(at)comcast(dot)net> writes:
> > Alvaro Herrera wrote:
> >> Just wondering, wouldn't it be enough to obtain a tuple count estimate
> >> by using reltuples / relpages * RelationGetNumberOfBlocks, like the
> >> planner does?
>
> > We thought of that and the verdict is still out whether it is more
> > costly to scan the entire relation to get the accurate count or use the
> > estimate and hope for the best with the possibility of splits occurring
> > during the build. If we use the estimate and it is completely wrong
> > (with the actual tuple count being much higher) the sort will provide no
> > benefit and it will behave as did the original code.
>
> I think this argument is *far* too weak to justify an extra pass over
> the relation. The planner-style calculation is quite unlikely to give a
> major underestimate of the rowcount. It might overestimate, eg if the
> relation is bloated by dead tuples, but an error in that direction won't
> kill you.

Agreed. Given the uncertainty in the hashing, calculating an exact
number of rows seems fruitless, whereas we know an extra scan will
certainly hurt. It might not show up in tests, but it will on life-size
tables.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Magnus Hagander 2007-09-27 09:59:44 Re: Warning is adjusted of pgbench.
Previous Message Simon Riggs 2007-09-27 07:20:51 Re: Minor recovery changes