Re: multicolumn index and setting effective_cache_size using human-readable-numbers
От | Geoff Winkless |
---|---|
Тема | Re: multicolumn index and setting effective_cache_size using human-readable-numbers |
Дата | |
Msg-id | CAEzk6fft5MXO3zFocsxna11gxmH4cYYFFrY6CDM_CokNFwN64w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: multicolumn index and setting effective_cache_size using human-readable-numbers (Geoff Winkless <pgsqladmin@geoff.dj>) |
Ответы |
Re: multicolumn index and setting effective_cache_size
using human-readable-numbers
|
Список | pgsql-general |
On 29 February 2016 at 14:07, Geoff Winkless <pgsqladmin@geoff.dj> wrote: > On 29 February 2016 at 14:06, Jim Mlodgenski <jimmy76@gmail.com> wrote: >> No they are not the same. When you don't include a unit for >> effective_cache_size, it defaults to page size so you're saying 2146435072 * >> 8K > > Hah. > > Thanks Jim, like I said I was sure I'd be missing something :) So ignoring my effective_cache_size vs units stupidity, and coming back to the problem I was originally going to email about before I got sidetracked... Is there a reason why the single-column index is used when effective_cache_size is so much lower, even though the index sizes are not much different (2.3GB vs 3.2GB)? I can increase effective_cache_size from (the current) 3GB up to 8GB before it starts using the multicolumn index, which seems excessive given the relative index sizes. Geoff
В списке pgsql-general по дате отправления: