From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Matthew Wakeling <matthew(at)flymine(dot)org>, Eliot Gable <egable+pgsql-performance(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: B-Heaps |
Date: | 2010-06-19 12:08:00 |
Message-ID: | AANLkTilUuGMWOQtmSszgWMsWA9DbbYEHZNaOfRum0d-V@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, Jun 18, 2010 at 1:53 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Matthew Wakeling wrote:
>>
>> This sort of thing has been fairly well researched at an academic level,
>> but has not been implemented in that many real world situations. I would
>> encourage its use in Postgres.
>
> I guess, but don't forget that work on PostgreSQL is driven by what problems
> people are actually running into. There's a long list of performance
> improvements sitting in the TODO list waiting for people to find time to
> work on them, ones that we're quite certain are useful. That anyone is
> going to chase after any of these speculative ideas from academic research
> instead of one of those is unlikely. Your characterization of the potential
> speed up here is "Using a proper tree inside the index page would improve
> the CPU usage of the index lookups", which seems quite reasonable.
> Regardless, when I consider "is that something I have any reason to suspect
> is a bottleneck on common workloads?", I don't think of any, and return to
> working on one of things I already know is instead.
This is drifting a bit off-topic for this thread, but it's not so easy
to figure out from looking at the TODO which things are actually
important. Performance-related improvements are mixed in with
non-performance related improvements, which are mixed in with things
that are probably not improvements at all. And even to the extent
that you can identify the stuff that's performance-related, it's far
from obvious which things are most important. Any thoughts on that?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Davor J. | 2010-06-19 19:38:14 | Slow function in queries SELECT clause. |
Previous Message | Scott Carey | 2010-06-19 02:59:14 | Re: requested shared memory size overflows size_t |