On 2016-10-28 11:23:22 +0530, Amit Kapila wrote: > On Wed, Oct 26, 2016 at 12:01 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers