On Wed, Oct 26, 2016 at 12:01 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2016-10-25 13:18:47 -0400, Tom Lane wrote:
>> (Frankly, I'm pretty skeptical of this entire patch being worth the
>> trouble...)
>
> The gains are quite noticeable in some cases. So if we can make it work
> without noticeable downsides...
>
+1.
> What I'm worried about though is that this, afaics, will quite
> noticeably *increase* total cost in cases with a noticeable number of
> columns and a not that selective qual. The reason for that being that
> HeapKeyTest() uses heap_getattr(), whereas upper layers use
> slot_getattr(). The latter "caches" repeated deforms, the former
> doesn't... That'll lead to deforming being essentially done twice, and
> it's quite often already a major cost of query processing.
>
heap_getattr() also has some caching mechanism to cache the tuple
offset , however it might not be as good as slot_getattr(). I think
if we decide to form the scan key from a qual only when qual refers to
fixed length column and that column is before any varlen column, the
increased cost will be alleviated. Do you have any other idea to
alleviate such cost?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
