DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	b=qtPWx8Qd6iZH7p4POii4u/0ybDuuUuQgbTGflPZAjIPPdYzJNIMihHem2XaCszaZX4
	SRNPfGCkEDOogCFhVEMBytlr55snuw0qrpcLzPspIRn8aK1QW79CszaGp3AGBsGH84oz
	Ld7iwiRlT2dtOYnLrnr+laJ2RP4D/cV628dDw=
Message-ID: <4D5504E5.3060901@gmail.com>
Date: Fri, 11 Feb 2011 11:44:05 +0200
From: Vitalii Tymchyshyn <tivv00@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: Tobias Brox <tobixen@gmail.com>
CC: Josh Berkus <josh@agliodbs.com>, pgsql-performance@postgresql.org,
	Mladen Gogala <mladen.gogala@vmsinfo.com>
Subject: Re: Why we don't want hints Was: Slow count(*) again...
References: <201102012247.p11Ml6u02682@momjian.us>
	<4D48914B.4050403@dunslane.net> <4D489AD1.1010105@vmsinfo.com>
	<AANLkTiknZi97dDwm7sHqy0EL7tpNEP9sY5uPV6AN+q=u@mail.gmail.com>
	<4D499E55.4020107@vmsinfo.com> <4D49A6B9.4060608@2ndquadrant.com>
	<4D49C482.4010707@vmsinfo.com> <4D49F0BA.9000901@2ndquadrant.com>
	<4D4A16BF.1020304@vmsinfo.com> <4D4A4844.3020409@2ndquadrant.com>
	<4D4AD9F6.6040903@vmsinfo.com> <4D4AE16E.9040807@peak6.com>
	<4D4B17B4.9030406@vmsinfo.com> <4D4B1F5B.4060403@peak6.com>
	<4D4B261B.6010303@vmsinfo.com>
	<AANLkTi=6_7N4EuT-trfPbxb9UmanJsnL+ineO-iJUFtJ@mail.gmail.com>
	<4D4B2E8A.7010402@vmsinfo.com> <4D4B3395.6010007@agliodbs.com>
	<4D4B394E.9080505@vmsinfo.com> <4D4B5A73.3080302@agliodbs.com>
	<AANLkTikCG8QUGpt7X=WEBnQCOio=R=zMLa_AoH4KCG2J@mail.gmail.com>
	<AANLkTi=tUc33HgqKdZOYVsaLSp0zQ7eeMyb+HcTWdNfH@mail.gmail.com>
	<AANLkTim+D5W3OyFWmXi0BA9xvP5yb5+Aja+Yfq0yOUFZ@mail.gmail.com>
In-Reply-To: <AANLkTim+D5W3OyFWmXi0BA9xvP5yb5+Aja+Yfq0yOUFZ@mail.gmail.com>
Content-Type: text/plain; charset=KOI8-U; format=flowed
Content-Transfer-Encoding: 8bit

11.02.11 11:29, Tobias Brox написав(ла):
> 2011/2/11 Віталій Тимчишин<tivv00@gmail.com>:
>> If the list is hard-coded, you can create partial index  on
>> account_transaction(account_id, created desc) where trans_type_id in ( ...
>> long, hard-coded list ...)
> My idea as well, though it looks ugly and it would be a maintenance
> head-ache (upgrading the index as new transaction types are added
> would mean "costly" write locks on the table,
Create new one concurrently.
>   and we can't rely on
> manual processes to get it right ... we might need to set up scripts
> to either upgrade the index or alert us if the index needs upgrading).
Yep. Another option could be to add query rewrite as

select  * from (
select * from account_transaction where trans_type_id =type1 and 
account_id=? order by created desc limit 25 union all
select * from account_transaction where trans_type_id =type2 and 
account_id=? order by created desc limit 25 union all
...
union all
select * from account_transaction where trans_type_id =typeN and 
account_id=? order by created desc limit 25
) a
order by created desc limit 25

This will allow to use three-column index in the way it can be used for 
such query. Yet if N is large query will look ugly. And I am not sure if 
optimizer is smart enough for not to fetch 25*N rows.


Best regards, Vitalii Tymchyshyn