| From: | Geoff Winkless <pgsqladmin(at)geoff(dot)dj> |
|---|---|
| To: | Geoff Winkless <pgsqladmin(at)geoff(dot)dj> |
| Cc: | Jim Mlodgenski <jimmy76(at)gmail(dot)com>, Postgres General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: multicolumn index and setting effective_cache_size using human-readable-numbers |
| Date: | 2016-02-29 14:19:45 |
| Message-ID: | CAEzk6fft5MXO3zFocsxna11gxmH4cYYFFrY6CDM_CokNFwN64w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 29 February 2016 at 14:07, Geoff Winkless <pgsqladmin(at)geoff(dot)dj> wrote:
> On 29 February 2016 at 14:06, Jim Mlodgenski <jimmy76(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vik Fearing | 2016-02-29 14:20:57 | Re: Only owners can ANALYZE tables...seems overly restrictive |
| Previous Message | Guillaume Lelarge | 2016-02-29 14:15:21 | Re: Only owners can ANALYZE tables...seems overly restrictive |