Re: Reducing NUMERIC size for 8.3
От | Simon Riggs |
---|---|
Тема | Re: Reducing NUMERIC size for 8.3 |
Дата | |
Msg-id | 1182179927.6855.190.camel@silverbirch.site обсуждение исходный текст |
Ответ на | Re: Reducing NUMERIC size for 8.3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Mon, 2007-06-18 at 10:54 -0400, Tom Lane wrote: > "Simon Riggs" <simon@2ndquadrant.com> writes: > > We've changed the on-disk database format in 8.3, so we have an > > opportunity to change other things also. There is a patch thats been on > > the patch queue for some time called numeric508, submitted Dec 2005; > > I thought that idea had been rejected long since as being an unreasonable > reduction in the flexibility of numeric arithmetic. I've re-read all of the posts from Dec 2005 and I see everyone in favour of committing the patch, subject to review of whether limitation to 508 was acceptable. For me that was never finalised, at least I can't see a clear decision. The important point is that the patch can be easily modified to overcome these restrictions, a line of thought that was never explored. The current patch can be easily modified to allow 1000 digits, yet still saving 2 bytes per value when storing more common values. Or we can use the same techniques to represent arbitrary number of digits, again still saving 2 bytes on common values. We have the ground work done, we just need to agree further changes. > > The benefit of the patch is that it reduces each NUMERIC value by 2 > > bytes, so will speed up things considerably. This is now especially > > important if we are looking to reduce the speed of numeric division by a > > factor of 4 (recent WIP patch). > > The only way that patch would make division faster is by making the > slowest cases (longest input numbers) impossible. Which is hardly a > solution. It isn't directly related to division, but is a speed up nonetheless which can offset the loss. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: