Message-ID: <52E7E9B3.6030101@vmware.com>
Date: Tue, 28 Jan 2014 19:32:35 +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: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: KNN-GiST with recheck
References: 
 <CAPpHfdu_qBLNRnv-r=_tofZYYa6-r=Z5_MGF4_phAOkWcYxfRg@mail.gmail.com>
 <52E7B6AD.9090608@vmware.com>
 <CAPpHfdvn5jxgh-rVMz7c2vXoYW_W7dGrJjQkVAtaCr=-ZMCADA@mail.gmail.com>
In-Reply-To: 
 <CAPpHfdvn5jxgh-rVMz7c2vXoYW_W7dGrJjQkVAtaCr=-ZMCADA@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 01/28/2014 04:12 PM, Alexander Korotkov wrote:
> On Tue, Jan 28, 2014 at 5:54 PM, Heikki Linnakangas <hlinnakangas@vmware.com
>> wrote:
>
>> 4. (as you mentioned in the other thread: ) It's a modularity violation
>> that you peek into the heap tuple from gist. I think the proper way to do
>> this would be to extend the IndexScan executor node to perform the
>> re-shuffling of tuples that come from the index in wrong order, or perhaps
>> add a new node type for it.
>>
>> Of course that's exactly what your partial sort patch does :-). I haven't
>> looked at that in detail, but I don't think the approach the partial sort
>> patch takes will work here as is. In the KNN-GiST case, the index is
>> returning tuples roughly in the right order, but a tuple that it returns
>> might in reality belong somewhere later in the ordering. In the partial
>> sort patch, the "input stream" of tuples is divided into non-overlapping
>> groups, so that the tuples within the group are not sorted, but the groups
>> are. I think the partial sort case is a special case of the KNN-GiST case,
>> if you consider the lower bound of each tuple to be the leading keys that
>> you don't need to sort.
>
> Yes. But, for instance btree accesses heap for unique checking. Is really
> it so crimilal? :-)

Well, it is generally considered an ugly hack in b-tree too. I'm not 
100% opposed to doing such a hack in GiST, but would very much prefer 
not to.

> This is not only question of a new node or extending existing node. We need
> to teach planner/executor access method can return value of some expression
> which is lower bound of another expression. AFICS now access method can
> return only original indexed datums and TIDs. So, I afraid that enormous
> infrastructure changes are required. And I can hardly imagine what they
> should look like.

Yeah, I'm not sure either. Maybe a new field in IndexScanDesc, along 
with xs_itup. Or as an attribute of xs_itup itself.

- Heikki


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