On Mon, Sep 22, 2008 at 11:25 PM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 14, 2008 at 8:16 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> BTW, one thing I noticed was that the hash index build time for the
>> "wide column" case got a lot worse after applying the patch (from 56 to
>> 237 sec).  The reason for this turned out to be that with the smaller
>> predicted index size, the code decided not to use the pre-sorting method
>> that was recently added.  Reducing effective_cache_size to less than the
>> index size brought the time back down, to about 54 sec.  So it would
>> seem that effective_cache_size is too large a cutoff value.  I'm
>> considering changing hashbuild to switch over at shared_buffers instead
>> of effective_cache_size --- any thoughts about that?
> Switching to shared_buffers gets my vote, on my test table with
> 50,000,000 rows it takes about 8 minutes to create an index using the
> default effective_cache_size.  With effective_cache_size set to 6GB
> (machine has 8GB) its still going an hour later.

Agreed.  I think using shared_buffers as a cutoff is a much better idea as well.

Jonah H. Harris, Senior DBA

Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:

Reply via email to