Re: Slow tab completion w/ lots of tables - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Slow tab completion w/ lots of tables
Date
Msg-id 20120821164731.GI1267@tamriel.snowman.net
Whole thread Raw
In response to Re: Slow tab completion w/ lots of tables  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Slow tab completion w/ lots of tables
Re: Slow tab completion w/ lots of tables
List pgsql-hackers
* 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

pgsql-hackers by date:

Previous
From: Nils Goroll
Date:
Subject: reviewing the "Reduce sinval synchronization overhead" patch / b4fbe392f8ff6ff1a66b488eb7197eef9e1770a4
Next
From: Tom Lane
Date:
Subject: Re: 9.2RC1 wraps this Thursday ...