From: | "ldh(at)laurent-hasson(dot)com" <ldh(at)laurent-hasson(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Marc Mamin <M(dot)Mamin(at)intershop(dot)de>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Inlining of functions (doing LIKE on an array) |
Date: | 2016-11-12 20:17:08 |
Message-ID: | 20161112201707.4870223.50246.53660@laurent-hasson.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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: ldh(at)laurent-hasson(dot)com
Cc: Marc Mamin; pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Inlining of functions (doing LIKE on an array)
"ldh(at)laurent-hasson(dot)com" <ldh(at)laurent-hasson(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pietro Pugni | 2016-11-14 11:45:38 | Some tuning suggestions on a Red Hat 6.7 - PG 9.5.3 production environment |
Previous Message | Tom Lane | 2016-11-12 19:59:32 | Re: Inlining of functions (doing LIKE on an array) |