* Robert Haas (robertmhaas@gmail.com) wrote:
> On Thu, Aug 16, 2012 at 10:37 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > When doing tab-completion under 9.1, pg_table_is_visible(oid) is slow
> > and is ending up as the first thing tested against all the rows
> > in pg_class. Increasing the cost of pg_table_is_visible() up to
> > 10 causes it to move to the end of the tests, which improves things
> > greatly- I thought there was a plan to make that the default..?
> >
> > This is with 9.1.4.
>
> Is this a regression versus earlier releases, or just a bad thing in general?
Alright, so, yea, the commit I was referring to is this one:
e84487f67a0d216f3db87b2558f1edd322a09e48
Which was apparently in the 8.3 dev cycle, so this would be an
8.2 -> 8.3 regression (as I mentioned in my last email, on this
particular database, we're going from 8.2 -> 9.1).
My vote is that everyone else needs to have databases with more tables,
or they need to care about tab-completion speed more. :) There are a
few complaints in the archives though, so I'm not alone..
Would changing the cost of pg_table_is_visible() require a catversion
bump..? Or maybe just do it w/o the bump for 9.2 and tell beta testers
that they might want to make the change by hand? Or bump it as part of
early 9.3?
I do also want to change tab-complete around a bit to make it so that we
can actually index the query based on the name, which would clearly be a
9.3 thing. I was expecting some push-back on this idea, but havn't
heard any yet. Would people accept adding an index on pg_class.relname
to support fast tab-completion? Or is this going to expand into
figuring out how to support index-based partial lookups for the 'name'
type, so we could use the existing index (if that's even possible to
do...)?
Thanks,
Stephen