| 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: | Whole Thread | Raw Message | 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
| 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 |