Re: How Postgresql Compares For Query And Load Operations
От | Mitch Vincent |
---|---|
Тема | Re: How Postgresql Compares For Query And Load Operations |
Дата | |
Msg-id | 000f01c111fc$8eab0d10$0200000a@Mitch обсуждение исходный текст |
Ответ на | How Postgresql Compares For Query And Load Operations (Mark kirkwood <markir@slingshot.co.nz>) |
Ответы |
Re: How Postgresql Compares For Query And Load Operations
|
Список | pgsql-general |
> A possible compromise is to make the accumulator be type "int8" for > int2 and int4 sums. You'd have to sum over at least 2^32 rows to > have any risk of overflow, which seems acceptable to me --- comments > anyone? I've noticed the speed issues with sum() and think that using the int8 accumulator would be acceptable as sum() is just about too slow to use in it's current state.. I spent a few hours yesterday optomizing some queries and actually found it faster to select all the rows and go through programmatically and sum the fields that I wanted rather than to use sum() so I'm all for just about anything that could speed it up. What's the story with count(), are there overflow fears there too? It doesn't seem to suffer from the performance problem that sum() does but I'm curious just the same... > Another consideration is what about machines without any 64-bit int > support. These machines would end up using a 32-bit int accumulator, > which would mean they'd be back to the pre-7.1 behavior in which sum() > could overflow. Is this okay? I wonder how many PG users this would affect..... Any idea? Thanks! -Mitch
В списке pgsql-general по дате отправления: