Re: Hash Index Build Patch

From: Tom Raney <twraney(at)comcast(dot)net>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Hash Index Build Patch
Date: 2007-09-26 19:43:03
Message-ID: 46FAB647.5040906@comcast.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Alvaro Herrera wrote:
> Hi Tom,
>
> Tom Raney wrote:
>
>
>> We used spool functions from the BTree code to sort the index
>> tuples. Sorting is done on the hash value of the tuples. The hash
>> value depends on the number of primary bucket pages (henceforth
>> just bucket pages) that will be required to fit all the index
>> tuples. So, before sorting, the base relation is scanned to get
>> the total number of tuples.
>>
>
> Just wondering, wouldn't it be enough to obtain a tuple count estimate
> by using reltuples / relpages * RelationGetNumberOfBlocks, like the
> planner does?
>
>
Hello Alvaro,

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.

But, to be honest, I don't know exactly when the catalog is updated and
how accurate the estimate is. If you have any information there (or
anyone else) please let me know. It would be great to eliminate that
extra pass!

Sincerely,
Tom Raney

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2007-09-26 20:06:28 Re: Hash Index Build Patch
Previous Message Tom Lane 2007-09-26 18:54:36 Re: Optimizer hook