Slow tab completion w/ lots of tables

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Slow tab completion w/ lots of tables
Date: 2012-08-17 02:37:41
Message-ID: 20120817023741.GZ1267@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

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.

After researching this a bit, I'm left wondering why we're using
substring() to do the matching test. I don't see any easy way to
index a substring() call which can be of any size (depending on how
many characters are preceding the user hitting 'tab'). On the other
hand, using LIKE with 'string%' and indexing with varchar_pattern_ops
should give us a nice index which could be used for tab completion,
right? If no one points out an obvious flaw in that, I'll take a look
at making that happen.

Thanks!

Stephen

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Gould 2012-08-17 02:53:33 Re: huge tlb support
Previous Message Bruce Momjian 2012-08-17 02:28:14 Re: Timing overhead and Linux clock sources