Re: Weird CASE WHEN behaviour causing query to be suddenly very slow
От | Tom Lane |
---|---|
Тема | Re: Weird CASE WHEN behaviour causing query to be suddenly very slow |
Дата | |
Msg-id | 16234.1427810310@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Weird CASE WHEN behaviour causing query to be suddenly very slow ("Kevin Viraud" <kevin.viraud@rocket-internet.de>) |
Ответы |
Re: Weird CASE WHEN behaviour causing query to be suddenly very slow
|
Список | pgsql-performance |
"Kevin Viraud" <kevin.viraud@rocket-internet.de> writes: > I have an issue with a rather large CASE WHEN and I cannot figure out why > it is so slow... Do all the arms of the CASE usually fail, leaving you at the ELSE? I suspect what's happening is that you're running into the MAX_CACHED_RES limit in src/backend/utils/adt/regexp.c, so that instead of just compiling each regexp once and then re-using 'em, the regexps are constantly falling out of cache and then having to be recompiled. They'd have to be used in a nearly perfect round robin in order for the behavior to have such a big cliff as you describe, though. In this CASE structure, that suggests that you're nearly always testing every regexp because they're all failing. I have to think there's probably a better way to do whatever you're trying to do, but there's not enough info here about your underlying goal to suggest a better approach. At the very least, if you need a many-armed CASE, it behooves you to make sure the common cases appear early. regards, tom lane
В списке pgsql-performance по дате отправления: