Message-ID: <5320A3D9.1010007@vmware.com>
Date: Wed, 12 Mar 2014 20:13:45 +0200
From: Heikki Linnakangas <hlinnakangas@vmware.com>
Organization: VMware
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20131103 Icedove/17.0.10
MIME-Version: 1.0
To: Alexander Korotkov <aekorotkov@gmail.com>
CC: Tomas Vondra <tv@fuzzy.cz>, pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: GIN improvements part2: fast scan
References: 
 <CAPpHfdvftaJq7www381naLw1=4u0h+qpXgWvNhcEB9HMVywbGg@mail.gmail.com>
 <52E4AA3A.9000607@fuzzy.cz> <52E53458.2010106@vmware.com>
 <CAPpHfdticvY2+RGTxzQdrr4YSQie+vYGRDRBTuG1ZxBmjwGrOA@mail.gmail.com>
 <CAPpHfduivz3MOA8_o+44n_Z0P-n+WCW=K1DrH+-g3gb-cbM2aA@mail.gmail.com>
 <CAPpHfdtDfQ1ycU0oh650uB5ND4+OY-enbfkweGWzXryCWD4UZA@mail.gmail.com>
 <CAPpHfdv792ZSWt_Tk+GzzsoNwm7ZGyomfrRiF7WuFN22LUVNUQ@mail.gmail.com>
 <CAPpHfdtSuSoZS4SwYQu4Rc8NOwDHoX3DsLGaxJF9HZ6gW0TdVA@mail.gmail.com>
 <52F36245.6070006@vmware.com>
 <CAPpHfdvMvEGXXUO0hpj=SU1tbVTpg1cP6kXjkyDqZpOD_9o7zQ@mail.gmail.com>
 <52F4E094.9040303@vmware.com>
 <CAPpHfdsMac=yQkkMi+HPN96EiCjvE1wBt9tveENq0tjti3r88w@mail.gmail.com>
 <5305CF6E.1080508@vmware.com>
 <CAPpHfdvUmurpcqQ83vWr-SKAdWzrOMxH+_XDQ-A=9bQTpjrnxg@mail.gmail.com>
 <CAPpHfdu18R9AG8-a_fB-eD2vpWtaydidM9TyRVFVY67R=SP7og@mail.gmail.com>
 <531F8994.3040008@fuzzy.cz> <53208B4D.5000806@vmware.com>
 <CAPpHfduJZiJAiR7qfOt2mH6kNbuBoQMbYJb9+7LgEb5pv53eHA@mail.gmail.com>
In-Reply-To: 
 <CAPpHfduJZiJAiR7qfOt2mH6kNbuBoQMbYJb9+7LgEb5pv53eHA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 03/12/2014 07:42 PM, Alexander Korotkov wrote:
> Preparation we do in startScanKey requires knowledge of estimate size of
> posting lists/trees. We do this estimate by traversal to leaf pages. I
> think gincostestimate is expected to be way more cheap. So, we probably
> need so more rough estimate there, don't we?

Yeah, maybe. We do something similar for b-tree MIN/MAX currently, but 
with a lot of keys, it could be a lot more expensive to traverse down to 
all of them.

I wonder if we could easily at least catch the common skewed cases, 
where e.g the logic of the consistent function is to AND all the keys. 
The opclass would know that, but we would somehow need to pass down the 
information to gincostestimate.

- Heikki


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers