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
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 |