On Fri, Jun 18, 2010 at 1:53 PM, Greg Smith <g...@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 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
