Thread: Small improvement to tlist_matches_tupdesc()
I just found myself in execScan.c. I noticed that tlist_matches_tupdesc() is a bit wasteful in some cases as it goes to the trouble of matching the tlist to the TupleDesc item by item until it runs out of tlist items or finds a non-match. Once the loop completes it ensures that all tlist items were consumed, so basically in other words, it checks the lengths match.
I think likely this was just not made optimal originally in d0b4399 when the length property etc were added to List
The attached patch adds a fast path so that no list items are compared if the lengths don't match.
Is this worth fixing?
--
David Rowley http://www.2ndQuadrant.com/
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachment
David Rowley <david.rowley@2ndquadrant.com> writes:
> I just found myself in execScan.c. I noticed that tlist_matches_tupdesc()
> is a bit wasteful in some cases as it goes to the trouble of matching the
> tlist to the TupleDesc item by item until it runs out of tlist items
> or finds a non-match. Once the loop completes it ensures that all tlist
> items were consumed, so basically in other words, it checks the lengths
> match.
> I think likely this was just not made optimal originally in d0b4399 when
> the length property etc were added to List
No, it's modeled after other places that allow for ignoring dropped
columns in one or both lists. While this code doesn't currently allow
that, the patch you suggest would prevent it from ever doing so (at least
not without reverting the patch first). I'd be okay with that if there
were evidence of a meaningful performance gain from it ... but you've
not provided any.
regards, tom lane