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 по дате отправления: