Re: hash index improving v3
От | Alex Hunsaker |
---|---|
Тема | Re: hash index improving v3 |
Дата | |
Msg-id | 34d269d40809222025k2b2252dft89db471649c8eef8@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: hash index improving v3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: hash index improving v3
|
Список | pgsql-patches |
On Sun, Sep 14, 2008 at 8:16 PM, Tom Lane <tgl@sss.pgh.pa.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.
В списке pgsql-patches по дате отправления: