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
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 |