On 8/20/24 20:41, Bruce Momjian wrote:
> On Tue, Aug 20, 2024 at 07:03:56PM +0200, Jelte Fennema-Nio wrote:
>> On Tue, 20 Aug 2024 at 18:50, Bruce Momjian <bruce@momjian.us> wrote:
>>> Okay, so we can do MAX easily, and AVG if the count can be represented
>>> as the same data type as the sum? Is that correct? Our only problem is
>>> that something like AVG(interval) can't use an array because arrays have
>>> to have the same data type for all array elements, and an interval can't
>>> represent a count?
>>
>> Close, but still not completely correct. AVG(bigint) can also not be
>> supported by patch 1, because the sum and the count for that both
>> stored using an int128. So we'd need an array of int128, and there's
>> currently no int128 SQL type.
>
> Okay. Have we considered having the FDW return a record:
>
> SELECT (oid, relname) FROM pg_class LIMIT 1;
> row
> ---------------------
> (2619,pg_statistic)
>
> SELECT pg_typeof((oid, relname)) FROM pg_class LIMIT 1;
> pg_typeof
> -----------
> record
>
> SELECT pg_typeof(oid) FROM pg_class LIMIT 1;
> pg_typeof
> -----------
> oid
>
> SELECT pg_typeof(relname) FROM pg_class LIMIT 1;
> pg_typeof
> -----------
> name
>
How would this help with the AVG(bigint) case? We don't have int128 as
SQL type, so what would be part of the record? Also, which part of the
code would produce the record? If the internal state is "internal", that
would probably need to be something aggregate specific, and that's kinda
what this patch series is adding, no?
Or am I missing some cases where the record would make it work?
regards
--
Tomas Vondra
