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

From Zdenek Kotala
Subject Re: Fix pgstatindex using for large indexes
Date
Msg-id 47C3DAB8.8000003@sun.com
Whole thread Raw
In response to Re: Fix pgstatindex using for large indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Tom Lane napsal(a):
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> Maybe we should just bite the bullet, and implement int64 emulation
>> for platforms that don't provide one?
>
> Why?  Workarounds such as "use double where needed" have served us
> perfectly fine so far, with far less effort and notational ugliness
> than this would involve.

Disadvantage of double usage is in CPUs. Current CPUs are perfectly
optimized for int operation but there are limitation for floating point
operatim. For example T1 (niagara) has only one FP unit per whole CPU
(T2 has one FP per core) and AMD64 has three parallel execution unit for
microcode  but only one for FP and FP shares registry with MMX unit.
And operation system has more work with saving FP register and so on...
Not all these limitations are related to PostgreSQL but it is good to know.

By my opinion avoid double is important in critical(bottleneck) places.
How you mentioned double is OK for pgstattuple.


> There will come a time where either there's a really good reason to rely
> on int64, or we feel that it's moot because any platform without int64
> is certainly dead anyway.  I'm not sure how far off that time is, but
> it's probably some fairly small number of years.

I don't think support more than five years older platform makes sense
for new version of PostgreSQL. Very often users buy a new hardware for
new database. IIRC all platform (x86, SPARC, MIPS, ALPHA, PARISC ...) do
not have problem with 64bit for longer time.

        Zdenek




pgsql-patches by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: lc_time and localized dates
Next
From: "Gevik Babakhani"
Date:
Subject: Re: lc_time and localized dates