Re: Inlining of functions (doing LIKE on an array)
От | ldh@laurent-hasson.com |
---|---|
Тема | Re: Inlining of functions (doing LIKE on an array) |
Дата | |
Msg-id | 20161112201707.4870223.50246.53660@laurent-hasson.com обсуждение исходный текст |
Ответ на | Re: Inlining of functions (doing LIKE on an array) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 pieceof 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@laurent-hasson.com Cc: Marc Mamin; pgsql-performance@postgresql.org Subject: Re: [PERFORM] Inlining of functions (doing LIKE on an array) "ldh@laurent-hasson.com" <ldh@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 beusing the inlining approach when possible, but the SQL Function approach is simpler and will likely be more suitable forsome 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
В списке pgsql-performance по дате отправления: