seq scan woes
| От | Dan Langille |
|---|---|
| Тема | seq scan woes |
| Дата | |
| Msg-id | 40C48DA6.3356.48DAC2EB@localhost обсуждение исходный текст |
| Ответы |
Re: seq scan woes
|
| Список | pgsql-performance |
A production system has had a query recently degrade in performance. What once took < 1s now takes over 1s. I have tracked down the problem to a working example. Compare http://rafb.net/paste/results/itZIx891.html with http://rafb.net/paste/results/fbUTNF95.html The first shows the query as is, without much change (actually, this query is nested within a larger query, but it demonstrates the problem). The query time is about 1 second. In the second URL, a "SET ENABLE_SEQSCAN TO OFF;" is done, and the time drops to 151ms, which is acceptable. What I don't understand is why the ports table is scanned in the first place. Clues please? -- Dan Langille : http://www.langille.org/ BSDCan - http://www.bsdcan.org/
В списке pgsql-performance по дате отправления: