Обсуждение: Do all rows from a set have the same TupleDesc?
Hi,
I have an user defined aggregate (Postgis' St_AsMVT) that receives rows as
input and I was wondering if all these tuples have the same TupleDesc.
In case it's important, here is how it's normally called:
```
SELECT St_AsMVT(q) FROM (
SELECT * FROM tilertest.tract9double
) q;
```
The idea behind this question is that, if this were true, I could cache
some information (number of attributes, oids, some internal stuff related
to each attribute) until the end of the aggregation to avoid having to
retrieve or calculate them for each one of the rows.
All the tests I've made seem to confirm this is true, but I was wondering if
there is any guarantee.
Regards
=?UTF-8?B?UmHDumwgTWFyw61uIFJvZHLDrWd1ZXo=?= <rmrodriguez@carto.com> writes:
> I have an user defined aggregate (Postgis' St_AsMVT) that receives rows as
> input and I was wondering if all these tuples have the same TupleDesc.
Yes, they should. It's possible that the tuples themselves might have
visible inconsistencies (primarily, smaller t_natts in some than the
tuple descriptor says), but as long as you confine yourself to using
the standard tuple-disassembly functions that won't matter.
> The idea behind this question is that, if this were true, I could cache
> some information (number of attributes, oids, some internal stuff related
> to each attribute) until the end of the aggregation to avoid having to
> retrieve or calculate them for each one of the rows.
Yeah, caching such info is common. It's traditional to code defensively
about the validity of the cache (see e.g. record_out), but I'm not sure
to what extent that's really necessary for aggregates. In the case of
record_out, paranoia is probably justified because FmgrInfo structs for
I/O functions may get cached and re-used across statements, but I doubt
that can happen for an aggregate.
regards, tom lane
Hi Tom,
> Yeah, caching such info is common. It's traditional to code defensively
> about the validity of the cache (see e.g. record_out), but I'm not sure
> to what extent that's really necessary for aggregates. In the case of
> record_out, paranoia is probably justified because FmgrInfo structs for
> I/O functions may get cached and re-used across statements, but I doubt
> that can happen for an aggregate.
The implementation of record_out is exactly what I was planning plus some
extra defenses. I'd consider the record type changing mid aggregation a
race condition, so I'll drop those checks.
Thanks a lot for the information.
Regards,