On Mon, Jan 5, 2015 at 12:54 PM, Tom Lane wrote:
> TBH, my first reaction to this entire patch is unfavorable: it's a
> solution in search of a problem. It adds substantial complication not
> only for users but for PG developers in order to solve a rather narrow
> performance issue.
>
> What woul
2015-01-05 Tom Lane :
> What would make sense to me is to teach the planner about inlining
> SQL functions that include ORDER BY clauses, so that the performance
> issue of a double sort could be avoided entirely transparently to
> the user.
Another way of getting to the point where the extra che
On Tue, Jan 6, 2015 at 4:15 PM, Jim Nasby wrote:
> On 1/6/15, 10:32 AM, Alvaro Herrera wrote:
>
>> Tom Lane wrote:
>>
>> What would make sense to me is to teach the planner about inlining
>>> SQL functions that include ORDER BY clauses, so that the performance
>>> issue of a double sort could be
On 1/6/15, 10:32 AM, Alvaro Herrera wrote:
Tom Lane wrote:
What would make sense to me is to teach the planner about inlining
SQL functions that include ORDER BY clauses, so that the performance
issue of a double sort could be avoided entirely transparently to
the user.
Wouldn't this be appli
On 1/5/15, 3:14 PM, Tom Lane wrote:
Jim Nasby writes:
Related... I'd like to see a way to inline a function that does something like:
CREATE FUNCTION foo(text) RETURNS int LANGUAGE sql AS $$
SELECT a FROM b WHERE lower(b.c) = lower($1)
$$
The reason that's not inlined ATM is that the seman
Tom Lane wrote:
> What would make sense to me is to teach the planner about inlining
> SQL functions that include ORDER BY clauses, so that the performance
> issue of a double sort could be avoided entirely transparently to
> the user.
Wouldn't this be applicable to functions in other languages t
On Tuesday, January 6, 2015, Amit Langote
wrote:
> On 06-01-2015 PM 04:26, Atri Sharma wrote:
> > On Tue, Jan 6, 2015 at 12:43 PM, Amit Langote <
> langote_amit...@lab.ntt.co.jp
> >> wrote:
> >> Though, I have no strong opinion on whether one thing is good or the
> >> other or whether they cover
Even checking whether the output of the function is in the right order or
not, has its cost. I am suggesting that we can eliminate this cost as well.
For example, PostgreSQL does not check whether a function is really
immutable or not.
>
> Best Wishes,
> Ashutosh Bapat
>
>
I imagine if it could b
Jim Nasby writes:
> Related... I'd like to see a way to inline a function that does something
> like:
> CREATE FUNCTION foo(text) RETURNS int LANGUAGE sql AS $$
> SELECT a FROM b WHERE lower(b.c) = lower($1)
> $$
The reason that's not inlined ATM is that the semantics wouldn't be the
same (ie,
On 1/5/15, 12:20 PM, Atri Sharma wrote:
What would make sense to me is to teach the planner about inlining
SQL functions that include ORDER BY clauses, so that the performance
issue of a double sort could be avoided entirely transparently to
the user.
It sounds good, but inlinin
On Mon, Jan 5, 2015 at 11:24 PM, Tom Lane wrote:
> David G Johnston writes:
> > Atri Sharma wrote
> >> If order of result rows is not the same as required, an error is raised:
> >>
> >> SELECT * FROM incorrect_order_nulls() ORDER BY e NULLS LAST;
> >> ERROR: Order not same as specified
>
> > Fi
David G Johnston writes:
> Atri Sharma wrote
>> If order of result rows is not the same as required, an error is raised:
>>
>> SELECT * FROM incorrect_order_nulls() ORDER BY e NULLS LAST;
>> ERROR: Order not same as specified
> First reaction for the error was unfavorable but (see below) it lik
Atri Sharma wrote
> If order of result rows is not the same as required, an error is raised:
>
> SELECT * FROM incorrect_order_nulls() ORDER BY e NULLS LAST;
> ERROR: Order not same as specified
First reaction for the error was unfavorable but (see below) it likely is
the best option and does ad
13 matches
Mail list logo
