Re: [PATCHES] Avg performance for int8/numeric

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCHES] Avg performance for int8/numeric
Дата
Msg-id 2164.1164599758@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCHES] Avg performance for int8/numeric  (Mark Kirkwood <markir@paradise.net.nz>)
Ответы Re: [PATCHES] Avg performance for int8/numeric  (Mark Kirkwood <markir@paradise.net.nz>)
Список pgsql-hackers
Mark Kirkwood <markir@paradise.net.nz> writes:
> Tom Lane wrote:
>> Most of this depends on being able to have a transition state value
>> that isn't any standard SQL datatype.  We've discussed that recently
>> in I-forget-what-context, and didn't find a good answer yet.

> Interesting, I didn't think of doing that - was considering creating a 
> suitable SQL composite type - a bit crass I guess, but I might just try 
> that out anyway and see what sort of improvement it gives (we can then 
> discuss how to do it properly in the advent that it's good....).

The thing is that (a) composite types have *at least* as much overhead
as arrays, probably rather more; and (b) a composite type in itself
doesn't allow non-SQL types as components, so still doesn't let you
tackle the idea of keeping the running sum in numeric.c's internal
calculation format.  So I don't think this will prove much --- the only
gain you can get is the count-in-int8-instead-of-numeric bit, which is
interesting but there is much left on the table.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: tiny fix needed
Следующее
От: "Ehab Galal"
Дата:
Сообщение: system table scan