| From: | Julian <tempura(at)internode(dot)on(dot)net> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Does it make sense to break a large query into separate functions? |
| Date: | 2013-05-08 14:40:59 |
| Message-ID: | 518A63FB.30406@internode.on.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 08/05/13 23:40, Seref Arikan wrote:
> Greetings,
>
> I have a domain specific language implementation that ends up as sql
> after an automatic transformation/code generation phase.
> The complexity of the generated sql queries can be significant, with
> lots of self joins and many other criteria injected into sql.
>
> I've just noticed that some parts of the autogenerated queries can be
> functions on their own. Would moving these parts to their own functions
> help the query planner?
>
> There are any two tables and all queries use them, so I thought the
> query planner may be able to do better if I let it deal with smaller
> queries rather than one quite large one. I don't know how the query
> planner works when there are calls to other functions from a function
> though.
>
> Changing the code generator would take time, so I decided to ask for
> more educated input than mine.
>
> Best regards
> Seref
>
Hi Seref,
The code generated sql queries isn't giving you much to work with (or a
choice). However I suspect its doing its best dealing with this data
structure (relationship model). I could be wrong.
But that might be where the problem is.
Regards,
Julian.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tobias Larsen | 2013-05-08 14:44:22 | SELECT count(*) differs from result in pgadmin |
| Previous Message | Julian | 2013-05-08 14:17:59 | Re: Design advice requested |