Re: [SQL] JOIN index/sequential select problem
От | Tom Lane |
---|---|
Тема | Re: [SQL] JOIN index/sequential select problem |
Дата | |
Msg-id | 26089.926549778@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | JOIN index/sequential select problem (gjerde@icebox.org) |
Ответы |
Re: [SQL] JOIN index/sequential select problem
|
Список | pgsql-sql |
gjerde@icebox.org writes: > Why in the world is postgres selecting seq scan on the inventorysuppliers > table when doing an LIKE? That doesn't make sense to me. I'm guessing you might be compiling with LOCALE support turned on? The parser's hack to make LIKE comparisons indexable is only half functional in that case, since you get the >= comparison but not the <= one. Given the small size of your tables, the optimizer is probably estimating that an index scan isn't going to be selective enough to justify its extra cost. FWIW, I do get an index scan plan on an attempt to duplicate this case... but I'm not using LOCALE. We need to figure out a way to make LIKE indexable in non-ASCII locales. I think the best bet might be to try to generate a string "one greater" than the given initial string. In other words, givenfield LIKE 'ABC%' we want to transform tofield LIKE 'ABC%' AND field >= 'ABC' AND field < 'ABD' so that the optimizer can use the last two clauses to constrain the index scan. But it's not real obvious how to generate a "larger" string in the general case with multibyte characters and non-straightforward collation order. Anyone have an idea how to do that? regards, tom lane
В списке pgsql-sql по дате отправления: