From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Raúl Marín Rodríguez <rmrodriguez(at)carto(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Do all rows from a set have the same TupleDesc? |
Date: | 2018-08-09 14:18:25 |
Message-ID: | 27424.1533824305@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
=?UTF-8?B?UmHDumwgTWFyw61uIFJvZHLDrWd1ZXo=?= <rmrodriguez(at)carto(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Cynthia Shang | 2018-08-09 14:37:28 | Re: Allow COPY's 'text' format to output a header |
Previous Message | Tom Lane | 2018-08-09 14:03:43 | Re: remove ancient pre-dlopen dynloader code |