Re: Progress on fast path sorting, btree index creation time - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Progress on fast path sorting, btree index creation time
Date
Msg-id CA+TgmobEJURfXpPE6pO0b0WA7_9FeomG2OEKkiXP0upV9M05_w@mail.gmail.com
Whole thread Raw
In response to Re: Progress on fast path sorting, btree index creation time  (Peter Geoghegan <peter@2ndquadrant.com>)
Responses Re: Progress on fast path sorting, btree index creation time  (Peter Geoghegan <peter@2ndquadrant.com>)
Re: Progress on fast path sorting, btree index creation time  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Fri, Jan 27, 2012 at 9:27 AM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> Well, I don't think it's all that subjective - it's more the case that
> it is just difficult, or it gets that way as you consider more
> specialisations.

Sure it's subjective.  Two well-meaning people could have different
opinions without either of them being "wrong".  If you do a lot of
small, in-memory sorts, more of this stuff is going to seem worthwhile
than if you don't.

> As for what types/specialisations may not make the cut, I'm
> increasingly convinced that floats (in the following order: float4,
> float8) should be the first to go. Aside from the fact that we cannot
> use their specialisations for anything like dates and timestamps,
> floats are just way less useful than integers in the context of
> database applications, or at least those that I've been involved with.
> As important as floats are in the broad context of computing, it's
> usually only acceptable to store data in a database as floats within
> scientific applications, and only then when their limitations are
> well-understood and acceptable. I think we've all heard anecdotes at
> one time or another, involving their limitations not being well
> understood.

While we're waiting for anyone else to weigh in with an opinion on the
right place to draw the line here, do you want to post an updated
patch with the changes previously discussed?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Progress on fast path sorting, btree index creation time
Next
From: Robert Haas
Date:
Subject: Re: Dry-run mode for pg_archivecleanup