On Mon, Jan 5, 2015 at 7:12 AM, Atri Sharma wrote:
>
> Hi All,
>
> Please forgive if this is a repost.
>
> Please find attached patch for supporting ORDER BY clause in CREATE
> FUNCTION for SRFs.
>
Hi Atri,
>From the discussion, I don't know if this patch is still being proposed.
If so, it need
On Tue, Jan 6, 2015 at 12:12 AM, Atri Sharma wrote:
> I will add the patch to current commitfest.
It has been indeed added to the commit fest 2014-12. That's a bit
late, moving it to upcoming one 2015-02.
Thanks,
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Not in all cases
postgres=# create function non_im_immutable_function() returns float as $$
begin
return *random()*;
end;
$$ language plpgsql *immutable*;
CREATE FUNCTION
postgres=# select proname, provolatile from pg_proc where proname =
'random' or proname = 'non_im_immutable_function';
On 07-01-2015 AM 08:33, Jim Nasby wrote:
> On 1/6/15, 1:00 AM, Ashutosh Bapat wrote:
>>
>> 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 fun
On 1/6/15, 1:00 AM, Ashutosh Bapat wrote:
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.
Actually, it
On 06-01-2015 PM 04:26, Atri Sharma wrote:
> On Tue, Jan 6, 2015 at 12:43 PM, Amit Langote > wrote:
>> Though, I have no strong opinion on whether one thing is good or the
>> other or whether they cover some particular use case all the same.
>> Perhaps you can say that better.
>>
>>
> Personally, I
On Tue, Jan 6, 2015 at 12:43 PM, Amit Langote wrote:
> On 06-01-2015 PM 04:08, Atri Sharma wrote:
> > On Tue, Jan 6, 2015 at 12:29 PM, Amit Langote <
> langote_amit...@lab.ntt.co.jp
>
>
> I read what Ashutosh says as that a clause like IMMUTABLE does not
> entail a node execution. Reading manual
On Tue, Jan 6, 2015 at 12:47 PM, Pavan Deolasee
wrote:
>
>
> On Tue, Jan 6, 2015 at 12:38 PM, Atri Sharma wrote:
>
>>
>>
> May be what Amit has in mind is that the planner can choose the most
> optimal sorting algorithm using the hint that the dataset is probably
> already sorted. Actually why n
On 06-01-2015 PM 04:08, Atri Sharma wrote:
> On Tue, Jan 6, 2015 at 12:29 PM, Amit Langote > wrote:
>>> 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 c
On Tue, Jan 6, 2015 at 12:38 PM, Atri Sharma wrote:
>
>
> On Tue, Jan 6, 2015 at 12:29 PM, Amit Langote <
> langote_amit...@lab.ntt.co.jp> wrote:
>
>>
>> >
>>
>> Sounds something like ORDERED BY x implying output is "known" ordered by
>> x perhaps enough hint for the planner to make necessary pla
On Tue, Jan 6, 2015 at 12:30 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
>
>
> On Tue, Jan 6, 2015 at 12:23 PM, Atri Sharma wrote:
>
>>
Even checking whether the output of the function is in the right order
> or not, has its cost. I am suggesting that we can elimin
On Tue, Jan 6, 2015 at 12:29 PM, Amit Langote wrote:
> On 06-01-2015 PM 04:00, Ashutosh Bapat wrote:
> > On Tue, Jan 6, 2015 at 12:23 PM, Atri Sharma
> wrote:
> >>> We can eliminate the new node and put onus or having the right order on
> >>> the user like we do with volatile setting of the func
On 06-01-2015 PM 04:00, Ashutosh Bapat wrote:
> On Tue, Jan 6, 2015 at 12:23 PM, Atri Sharma wrote:
>>> We can eliminate the new node and put onus or having the right order on
>>> the user like we do with volatile setting of the function.
>>>
>>>
>>
>> That is exactly what the new node does, since
On Tue, Jan 6, 2015 at 12:23 PM, Atri Sharma wrote:
>
>>>
>>> The overhead of this patch is small. A new path is added for the
>>> preorder keys, and OrderCheck node's additional cost is pretty low, given
>>> that it only compares two rows and stores only a single row (previous row
>>> seen), hen
>
>
>>
>> The overhead of this patch is small. A new path is added for the preorder
>> keys, and OrderCheck node's additional cost is pretty low, given that it
>> only compares two rows and stores only a single row (previous row seen),
>> hence the memory footprint is minuscule.
>>
>>
> We can elim
On Mon, Jan 5, 2015 at 8:42 PM, Atri Sharma wrote:
>
> Hi All,
>
> Please forgive if this is a repost.
>
> Please find attached patch for supporting ORDER BY clause in CREATE
> FUNCTION for SRFs. Specifically:
>
> CREATE OR REPLACE FUNCTION func1(OUT e int, OUT f int) returns setof
> record as '
Hi All,
Please forgive if this is a repost.
Please find attached patch for supporting ORDER BY clause in CREATE
FUNCTION for SRFs. Specifically:
CREATE OR REPLACE FUNCTION func1(OUT e int, OUT f int) returns setof record
as ' SELECT a,b FROM table1 ORDER BY a; ' language 'sql' ORDER BY e;
This
17 matches
Mail list logo
