Re: Fix pgstatindex using for large indexes - Mailing list pgsql-patches

From Tom Lane
Subject Re: Fix pgstatindex using for large indexes
Date
Msg-id 27782.1203956478@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fix pgstatindex using for large indexes  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Responses Re: Fix pgstatindex using for large indexes  (Andrew Dunstan <andrew@dunslane.net>)
Re: Fix pgstatindex using for large indexes  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Fix pgstatindex using for large indexes  ("Florian G. Pflug" <fgp@phlo.org>)
List pgsql-patches
Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> Tom Lane napsal(a):
>> Most places where we've dealt with this before, we use double, which is
>> guaranteed to be available whereas uint64 is not ...

> Is this requirement still valid?

Yes.

> Is there any currently supported platform which
> does not have uint64?

I don't know, and neither do you.

> IIRC we are going to change datetime to integer for 8.4.

We are going to change the *default* to integer.  It will still be
possible to select float datetimes for use on platforms without working
int64.  There is not any core functionality that will fail completely
without int64, and none will be introduced anytime soon if I have
anything to say about it.

Now having said that, there are places that use int64 with the
understanding that it might degrade to int32, and that that will be
good enough --- the statistics counters are an example.  However,
the only point of the patch being presented for pgstatindex is to
be able to count higher than 2^32, so ISTM we may as well make it
use double.  There isn't any particular reason it *shouldn't* be
coded that way, AFAICS, and there is precedent in that VACUUM/ANALYZE
use doubles for similar purposes.

            regards, tom lane

pgsql-patches by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: lc_time and localized dates
Next
From: Andrew Dunstan
Date:
Subject: Re: Fix pgstatindex using for large indexes