Yep, agreed. A simple lexical macro-like approach to test "if it works" could
be a simple approach to see if inlining a piece of sql would not break the main
query?
Laurent Hasson
Sent from my BlackBerry Passport
Original Message
From: Tom Lane
Sent: Saturday, November 12, 2016 14:59
To: l...@laurent-hasson.com
Cc: Marc Mamin; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Inlining of functions (doing LIKE on an array)
"l...@laurent-hasson.com" <l...@laurent-hasson.com> writes:
> I wish there were a way to force inlining, or some other mechanism as the
> performance difference is large here. I'll be using the inlining approach
> when possible, but the SQL Function approach is simpler and will likely be
> more suitable for some developers.
I'm not sure that there's any fundamental reason why we don't inline SQL
functions containing sub-selects. It may just be not having wanted to put
any effort into the case way-back-when. Inlining happens too late to
allow a resulting WHERE EXISTS to get mutated into a semijoin, but in this
example that couldn't happen anyway, so it's not much of an objection.
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
