On Fri, Jun 18, 2010 at 1:53 PM, Greg Smith <greg@2ndquadrant.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