Re: Whole row var issue

On Thu, 6 Aug 2026 at 12:54, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> Alternatively, we could rewrite the missing attributes starting at the
> tuple's natts with each deform iteration, and that would put the extra
> overhead just into the has-missing-attribute code path. It's probably
> possible to form some wild case that ends up with some quadratic
> overhead because only 1 extra attribute is being deformed with each
> pass, but that plan probably is slow for other reasons anyway, so it
> might be better doing it that way so as not to add the overhead to the
> common path.

I push this version instead. We already don't focus much on optimising
the case where we deform in multiple passes that much (e.g., calling
populate_isnull_array() from the start of the tuple again). IMO, it's
more reasonable to make deforming missing attributes in multiple
passes slightly slower at the expense of not adding any overhead to
the happy path. I spent too long on that happy path to want to add any
more instructions to it. I really doubt deforming multiple missing
attributes in separate deform passes is common. We'd have had a report
about this much sooner if it were.

David