Re: Slow tab completion w/ lots of tables

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Thu, Aug 16, 2012 at 10:37 PM, Stephen Frost <sfrost(at)snowman(dot)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