Re: indexes on float8 vs integer

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Dennis Gearon <gearond(at)sbcglobal(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: indexes on float8 vs integer
Date: 2009-07-12 07:27:25
Message-ID: dcc563d10907120027h5f13602aqaf92409b7e8c0b88@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, Jul 11, 2009 at 10:15 PM, Dennis Gearon<gearond(at)sbcglobal(dot)net> wrote:
>
> Anyone got any insight or experience in the speed and size of indexes on Integer(4 byte) vs float (8byte). For a project that I'm on, I'm contemplating using an integer for:
>
>     Latitude
>     Longitude
>
> In a huge, publically searchable table.
>
> In the INSERTS, the representation would be equal to:
>
>     IntegerLatOrLong = to_integer( float8LatOrLong * to_float(1000000) );
>
> This would keep it in a smaller (4 bytes vs 8 byte) representation with simple numeric comparison for indexing values while still provide 6 decimals of precision, i.e. 4.25 inches of resolution, what google mapes provides.
>
> I am expecting this table to be very huge. Hey, I want to be the next 'portal' :-)
> Dennis Gearon

Well, floats can be bad if you need exact math or matching anyway, and
math on them is generally slower than int math. OTOH, you could look
into numeric to see if it does what you want. Used to be way slower
than int, but in recent versions of pgsql it's gotten much faster.
Numeric is exact, where float is approximate, so if having exact
values be stored is important, then either using int and treating it
like fixed point, or using numeric is usually better.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Craig Ringer 2009-07-12 08:28:15 Re: INSERT only unique records
Previous Message Scott Marlowe 2009-07-12 07:23:48 Re: Weird disk/table space consumption problem