Slow tab completion w/ lots of tables
| От | Stephen Frost |
|---|---|
| Тема | Slow tab completion w/ lots of tables |
| Дата | |
| Msg-id | 20120817023741.GZ1267@tamriel.snowman.net обсуждение исходный текст |
| Ответы |
Re: Slow tab completion w/ lots of tables
|
| Список | 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
againstall the rows in pg_class. Increasing the cost of pg_table_is_visible() up to 10 causes it to move to the end of
thetests, 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
easyway 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
niceindex which could be used for tab completion, right? If no one points out an obvious flaw in that, I'll take a
lookat making that happen.
Thanks!
Stephen
В списке pgsql-hackers по дате отправления: