Re: Slow tab completion w/ lots of tables

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> 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).

Uh, no, that was in the 7.4 cycle.

> My vote is that everyone else needs to have databases with more tables,
> or they need to care about tab-completion speed more. :)

Agreed, but we're not doing anything about that in 9.2.

> 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...)?

The LIKE idea is interesting. What you'd still need is to suppress the
quote_ident function call so that it becomes just "relname LIKE 'foo%'".
Which seems do-able if possibly rather ugly. That would leave us with
SELECT ... FROM foo<TAB> being fast but SELECT ... FROM "foo<TAB> being
slow; not sure if that's good enough. I do *not* want to add an index
on quote_ident(relname) to pg_class though. Quite aside from speed
issues, I'm pretty sure that functional indexes on core system catalogs
would be a huge can of worms.

regards, tom lane