| From: | Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
| Subject: | Re: Re: Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs |
| Date: | 2015-01-07 09:06:04 |
| Message-ID: | CAP-rdTbYq-S9edKxDeB7XHGQ=zYnpXdHuoSQ1Cg_+Atn5PTKcg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
2015-01-05 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> 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 check-node is not
needed in obvious cases, would be:
* Apply the current patch in some form.
* Later, add code that analyzes the query inside the function. If it
turns out that the result of the analysis implies the declared order,
don't add the check-node.
The analysis can in principle also be performed for other languages,
but that would most likely be way more complex for the typical "Turing
complete" languages.
Nicolas
--
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Bapat | 2015-01-07 09:24:50 | Re: Transactions involving multiple postgres foreign servers |
| Previous Message | Dean Rasheed | 2015-01-07 09:04:24 | Re: INSERT ... ON CONFLICT UPDATE and RLS |