From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
Subject: | Re: PoC plpgsql - possibility to force custom or generic plan |
Date: | 2017-04-05 21:22:34 |
Message-ID: | 1010.1491427354@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> I'd like some input from other committers whether we want this. I'm
> somewhat doubtful, but don't have particularly strong feelings.
I don't really want to expose the workings of the plancache at user level.
The heuristics it uses certainly need work, but it'll get hard to change
those once there are SQL features depending on it.
Also, as you note, there are debatable design decisions in this particular
patch. There are already a couple of ways in which control knobs can be
attached to plgsql functions (i.e. custom GUCs and the comp_option stuff),
so why is this patch wanting to invent yet another fundamental mechanism?
And I'm not very happy about it imposing a new reserved keyword, either.
A bigger-picture question is why we'd only provide such functionality
in plpgsql, and not for other uses of prepared plans.
Lastly, it doesn't look to me like the test cases prove anything at all
about whether the feature does what it's claimed to.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Palmiotto | 2017-04-05 21:29:10 | Re: partitioned tables and contrib/sepgsql |
Previous Message | Pavel Stehule | 2017-04-05 20:53:39 | Re: possible encoding issues with libxml2 functions |