From: "Kevin Viraud" <kevin.viraud@rocket-internet.de>
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>
Cc: <pgsql-performance@postgresql.org>
References: <00a001d06b90$2d1bbe80$87533b80$@rocket-internet.de>
 <16234.1427810310@sss.pgh.pa.us>
In-Reply-To: <16234.1427810310@sss.pgh.pa.us>
Subject: Re: Weird CASE WHEN behaviour causing query to be suddenly very slow
Date: Tue, 31 Mar 2015 17:58:57 +0200
Message-ID: <00d301d06bcb$997cf220$cc76d660$@rocket-internet.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQECQJ6lxjgMF7czE/gsntwULz0zEwHZauBnnsQ1RSA=
Content-Language: de
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Touche ! Thanks a lot.

Looking more at the data yes it goes very often to ELSE Clause.  And
therefore reaching  the MAX_CACHED_RES.=20

In there anyway to increase that value  ?

Basically, I have several tables containing millions of rows and let say 5
columns. Those five columns, depending of their  combination give me a 6th
value.=20=20
We have complex patterns to match and using simple LIKE / EQUAL and so on
wouldn't be enough. This can be applied to N number of table so we
refactored this process into a function that we can use in the SELECT
statement, by giving only the 5 values each time.

I wouldn't mind using a table and mapping it through a join  if it were for
my own use.=20
But the final query has to be readable and usable for almost-non-initiated
SQL user... So using a function with encapsulated case when seemed to be a
good idea and so far worked nicely.=20

But we might consider changing it if we have no other choice...

Regards,

Kevin

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]=20
Sent: Dienstag, 31. M=E4rz 2015 15:59
To: Kevin Viraud
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Weird CASE WHEN behaviour causing query to be
suddenly very slow

"Kevin Viraud" <kevin.viraud@rocket-internet.de> writes:
> I have an issue with a rather large CASE WHEN and I cannot figure out=20
> 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


--=20
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance