Message-ID: <4CA2F2BC.8090307@catalyst.net.nz>
Date: Wed, 29 Sep 2010 21:03:08 +1300
From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: Memory usage - indexes
References: <AANLkTimd0Y7KhnwkSXz4FYjsxC8ocDeRRH=PXvU1a3vv@mail.gmail.com>
	<AANLkTim_Ba7_Am6aoR52tZi_gU5QR8QB99e4m_BuwvGX@mail.gmail.com>
In-Reply-To: <AANLkTim_Ba7_Am6aoR52tZi_gU5QR8QB99e4m_BuwvGX@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 29/09/10 19:41, Tobias Brox wrote:
> I just got this crazy, stupid or maybe genius idea :-)
>
>
> Now, my idea is to drop that fat index and replace it with conditional
> indexes for a dozen of heavy users - like those:
>
>    acc_trans(trans_type, created) where customer_id=224885;
>    acc_trans(trans_type, created) where customer_id=643112;
>    acc_trans(trans_type, created) where customer_id=15;
>
> or maybe like this:
>
>    acc_trans(customer_id, trans_type, created) where customer_id in ( ... );
>
> Any comments?
>
> My sysadmin is worried that it would be a too big hit on performance
> when doing inserts.  It may also cause more overhead when planning the
> queries.  Is that significant?  Is this idea genius or stupid or just
> somewhere in between?
>
>    

Yeah, I think the idea of trying to have a few smaller indexes for the 
'hot' customers is a good idea. However I am wondering if just using 
single column indexes and seeing if the bitmap scan/merge of smaller 
indexes is actually more efficient is worth testing - i.e:

acc_trans(trans_type);
acc_trans(created);
acc_trans(customer_id);

It may mean that you have to to scrutinize your effective_cache_size and 
work_mem parameters, but could possibly be simpler and more flexible.

regards

Mark