Re: Progress on fast path sorting, btree index creation time

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Progress on fast path sorting, btree index creation time
Date: 2012-01-27 14:37:37
Message-ID: CA+TgmobEJURfXpPE6pO0b0WA7_9FeomG2OEKkiXP0upV9M05_w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 27, 2012 at 9:27 AM, Peter Geoghegan <peter(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-01-27 14:47:54 Re: Dry-run mode for pg_archivecleanup
Previous Message Peter Geoghegan 2012-01-27 14:27:36 Re: Progress on fast path sorting, btree index creation time