From: | "Alex Hunsaker" <badalex(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Kenneth Marshall" <ktm(at)rice(dot)edu>, "Xiao Meng" <mx(dot)cogito(at)gmail(dot)com>, "Zdenek Kotala" <Zdenek(dot)Kotala(at)sun(dot)com>, pgsql-patches(at)postgresql(dot)org, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com> |
Subject: | Re: hash index improving v3 |
Date: | 2008-09-23 03:25:03 |
Message-ID: | 34d269d40809222025k2b2252dft89db471649c8eef8@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On Sun, Sep 14, 2008 at 8:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-09-23 03:28:46 | Re: [patch] fix dblink security hole |
Previous Message | Greg Sabino Mullane | 2008-09-23 02:31:05 | pg_type.h regression? |
From | Date | Subject | |
---|---|---|---|
Next Message | Jonah H. Harris | 2008-09-23 03:30:58 | Re: hash index improving v3 |
Previous Message | Alex Hunsaker | 2008-09-23 01:57:16 | Re: hash index improving v3 |