On 2016-10-28 11:23:22 +0530, Amit Kapila wrote:
> On Wed, Oct 26, 2016 at 12:01 PM, Andres Freund <andres@anarazel.de> wrote:
> > 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().
It's most definitely not as good. In fact, my measurements show it to be
a net negative in a number of cases.
> 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?
Well, that'll also make the feature not particularly useful :(. My
suspicion is that the way to suceed here isn't to rely more on testing
as part of the scan, but create a more general fastpath for qual
evaluation, which atm is a *LOT* more heavyweight than what
HeapKeyTest() does. But maybe I'm biased since I'm working on the
latter...
Andres