On 08/30/2014 12:15 AM, Kevin Grittner wrote:
Heikki Linnakangas wrote:
On 08/28/2014 12:03 AM, Kevin Grittner wrote:
Heikki Linnakangas wrote:
I suggest adding a new hook to the ParseState struct, (p_rangevar_hook
?). The planner calls it whenever it sees a reference to a table, and
the hoo
Kevin Grittner wrote:
> Kevin Grittner wrote:
> executor-tuplestore-relations covers parse analysis,
> planner/optimizer, and executor layers.
> 30 files changed, 786 insertions(+), 9 deletions(-)
Testing and further review found a few places that needed to add
lines for the new RTE kind that
Heikki Linnakangas wrote:
> On 08/28/2014 12:03 AM, Kevin Grittner wrote:
>> Heikki Linnakangas wrote:
>>> I suggest adding a new hook to the ParseState struct, (p_rangevar_hook
>>> ?). The planner calls it whenever it sees a reference to a table, and
>>> the hook function returns back some sort
On Thu, Aug 28, 2014 at 12:03 AM, Kevin Grittner wrote:
>> In essence, make the relations work like PL/pgSQL
>> variables do. If you squint a little, the new/old relation is a variable
>> from the function's point of view, and a parameter from the
>> planner/executor's point of view. It's just a v
On 08/28/2014 12:03 AM, Kevin Grittner wrote:
Heikki Linnakangas wrote:
I suggest adding a new hook to the ParseState struct, (p_rangevar_hook
?). The planner calls it whenever it sees a reference to a table, and
the hook function returns back some sort of placeholder reference to the
tuplestor
* Kevin Grittner (kgri...@ymail.com) wrote:
> Heikki Linnakangas wrote:
> > In essence, make the relations work like PL/pgSQL
> > variables do. If you squint a little, the new/old relation is a variable
> > from the function's point of view, and a parameter from the
> > planner/executor's point of
Jim Nasby wrote:
> Something to keep in mind is that users will definitely think about NEW/OLD as
> tables. I suspect that it won't be long after release before someone asks
> why they can't create an index on it. :)
I'm comfortable saying "No" to that. But it's a good point -- I'll
review err
Heikki Linnakangas wrote:
> On 08/27/2014 02:26 AM, Kevin Grittner wrote:
>> spi-tuplestore-registry allows tuplestores, with associated name
>> and TupleDesc, to be registered with the current SPI connection.
>> Queries planned or executed on that connection will recognize the
>> name as a tuple
On Wed, Aug 27, 2014 at 11:51:40AM -0500, Jim Nasby wrote:
> On 8/27/14, 2:23 AM, Heikki Linnakangas wrote:
> >Does this make sense? In essence, make the relations work like
> >PL/pgSQL variables do. If you squint a little, the new/old relation
> >is a variable from the function's point of view, an
On 8/27/14, 2:23 AM, Heikki Linnakangas wrote:
Does this make sense? In essence, make the relations work like PL/pgSQL
variables do. If you squint a little, the new/old relation is a variable from
the function's point of view, and a parameter from the planner/executor's point
of view. It's jus
On 08/27/2014 02:26 AM, Kevin Grittner wrote:
spi-tuplestore-registry allows tuplestores, with associated name
and TupleDesc, to be registered with the current SPI connection.
Queries planned or executed on that connection will recognize the
name as a tuplestore relation. It doesn't care who is
Kevin Grittner wrote:
> I think this is approaching a committable state, although I think
> it should probably be broken down to four separate patches.
And here they are. This should net to the same set of changes as
the prior post, but the changes are logically separated. They are
labeled as
Amit Khandekar wrote:
> On 15 August 2014 04:04, Kevin Grittner wrote:
>> The identifiers in the trigger function are not resolved to
>> particular objects until there is a request to fire the trigger.
> Ah ok, you are talking about changes specific to the PL language
> handlers. Yes, I agree th
On 15 August 2014 04:04, Kevin Grittner wrote:
> Amit Khandekar wrote:
>
The execution level itself was almost trivial; it's getting the
tuplestore reference through the parse analysis and planning
phases that is painful for me.
>>> I am not sure why you think we would need to refe
Amit Khandekar wrote:
>>> The execution level itself was almost trivial; it's getting the
>>> tuplestore reference through the parse analysis and planning
>>> phases that is painful for me.
>> I am not sure why you think we would need to refer the
>> tuplestore in the parse analysis and planner p
>> The execution level
>> itself was almost trivial; it's getting the tuplestore reference
>> through the parse analysis and planning phases that is painful for
>> me.
> I am not sure why you think we would need to refer the tuplestore in
> the parse analysis and planner phases. It seems that we wo
On 12 August 2014 20:09, Kevin Grittner wrote:
> Amit Khandekar wrote:
>> On 7 August 2014 19:49, Kevin Grittner wrote:
>>> Amit Khandekar wrote:
>
I tried to google some SQLs that use REFERENCING clause with triggers.
It looks like in some database systems, even the WHEN clause of CR
Amit Khandekar wrote:
> On 7 August 2014 19:49, Kevin Grittner wrote:
>> Amit Khandekar wrote:
>>> I tried to google some SQLs that use REFERENCING clause with triggers.
>>> It looks like in some database systems, even the WHEN clause of CREATE
>>> TRIGGER
>>> can refer to a transition table,
On 7 August 2014 19:49, Kevin Grittner wrote:
> Amit Khandekar wrote:
>> On 21 June 2014 23:36, Kevin Grittner wrote:
>>> Kevin Grittner wrote:
>>> I didn't change the tuplestores to TID because it seemed to me that
>>> it would preclude using transition relations with FDW triggers, and
>>> it
Thanks for your review and comments, Amit!
Amit Khandekar wrote:
> On 21 June 2014 23:36, Kevin Grittner wrote:
>> Kevin Grittner wrote:
>> I didn't change the tuplestores to TID because it seemed to me that
>> it would preclude using transition relations with FDW triggers, and
>> it seemed bad
On 21 June 2014 23:36, Kevin Grittner wrote:
> Kevin Grittner wrote:
> I didn't change the tuplestores to TID because it seemed to me that
> it would preclude using transition relations with FDW triggers, and
> it seemed bad not to support that. Does anyone see a way around
> that, or feel that
Marti Raudsepp wrote:
> The real point I was trying to convey (in my previous email) is
> that these declarations should be part of the trigger *function*
> not the function-to-table relationship. CREATE TRIGGER shouldn't
> be in the business of declaring new local variables for the
> trigger fun
2014-07-29 9:41 GMT+02:00 Marti Raudsepp :
> On Tue, Jul 29, 2014 at 9:49 AM, Pavel Stehule
> wrote:
> > I dislike this proposal - it is strongly inconsistent with current
> trigger
> > design
>
> The real point I was trying to convey (in my previous email) is that
> these declarations should be
On Tue, Jul 29, 2014 at 9:49 AM, Pavel Stehule wrote:
> I dislike this proposal - it is strongly inconsistent with current trigger
> design
The real point I was trying to convey (in my previous email) is that
these declarations should be part of the trigger *function* not the
function-to-table re
2014-07-28 19:27 GMT+02:00 Marti Raudsepp :
> On Mon, Jul 28, 2014 at 6:24 PM, Kevin Grittner wrote:
> > Do you have some other suggestion? Keep in mind that it must allow
> > the code which will *generate* the transition tables to know
> > whether any of the attached triggers use a given transi
On Mon, Jul 28, 2014 at 6:24 PM, Kevin Grittner wrote:
> Do you have some other suggestion? Keep in mind that it must allow
> the code which will *generate* the transition tables to know
> whether any of the attached triggers use a given transition table
> for the specific operation, regardless o
Marti Raudsepp wrote:
> On Sat, Jul 5, 2014 at 5:38 PM, Kevin Grittner wrote:
>> it seems to me that we need the full tuple to support triggers on
>> FDWs, so the TID approach would be an optimization for a subset of
>> the cases, and would probably be more appropriate, if we do it at
>> all, in
On Sat, Jul 5, 2014 at 5:38 PM, Kevin Grittner wrote:
> it seems to me that we need the full tuple to support triggers on
> FDWs, so the TID approach would be an optimization for a subset of
> the cases, and would probably be more appropriate, if we do it at
> all, in a follow-on patch
> If you di
Kevin Grittner wrote:
> Because this review advances the patch so far, it may be feasible
> to get it committed in this CF. I'll see what is needed to get
> there and maybe have a patch toward that end in a few days.
It appears that I need to create a new execution node and a way for
SPI calls
David Fetter wrote:
> It's missing a few pieces like surfacing transition table names.
> I'll work on those. Also, it's not clear to me how to access the
> pre- and post- relations at the same time, this being necessary
> for many use cases. I guess I need to think more about how that
> would
On Mon, Jun 30, 2014 at 11:03:06AM -0400, Robert Haas wrote:
> On Sat, Jun 28, 2014 at 10:35 AM, Kevin Grittner wrote:
> > David Fetter wrote:
> >> On Sat, Jun 21, 2014 at 11:06:26AM -0700, Kevin Grittner wrote:
> >
> >>> Here is v2.
> >
> >> I've taken the liberty of making an extension that use
On Sat, Jun 28, 2014 at 10:35 AM, Kevin Grittner wrote:
> David Fetter wrote:
>> On Sat, Jun 21, 2014 at 11:06:26AM -0700, Kevin Grittner wrote:
>
>>> Here is v2.
>
>> I've taken the liberty of making an extension that uses this.
>> Preliminary tests indicate a 10x performance improvement over th
On Sat, Jun 28, 2014 at 07:35:10AM -0700, Kevin Grittner wrote:
> David Fetter wrote:
> > On Sat, Jun 21, 2014 at 11:06:26AM -0700, Kevin Grittner wrote:
>
> >> Here is v2.
>
> > I've taken the liberty of making an extension that uses this.
> > Preliminary tests indicate a 10x performance improv
David Fetter wrote:
> On Sat, Jun 21, 2014 at 11:06:26AM -0700, Kevin Grittner wrote:
>> Here is v2.
> I've taken the liberty of making an extension that uses this.
> Preliminary tests indicate a 10x performance improvement over the
> user-space hack I did that's similar in functionality.
Wow,
On Sat, Jun 21, 2014 at 11:06:26AM -0700, Kevin Grittner wrote:
> Kevin Grittner wrote:
> > Kevin Grittner wrote:
> >
> >> I've already said that I now think we should use the standard
> >> CREATE TRIGGER syntax to specify the transition tables, and that
> >> if we do that we don't need the relop
Kevin Grittner wrote:
> I've already said that I now think we should use the standard
> CREATE TRIGGER syntax to specify the transition tables, and that
> if we do that we don't need the reloption that's in the patch.
> If you ignore the 19 lines of new code to add that reloption,
> absolutely 1
David Fetter wrote:
> On Wed, Jun 18, 2014 at 03:30:34PM -0700, Kevin Grittner wrote:
>> the more I think about it (and discuss it) the more I'm
>> inclined to suffer the additional complexity of the standard
>> syntax for specifying transition relations in order to avoid
>> unnecessary overhead
On Wed, Jun 18, 2014 at 03:30:34PM -0700, Kevin Grittner wrote:
> David Fetter wrote:
> > Robert Haas wrote:
> >> Kevin Grittner wrote:
>
> > The good:
> > - Generating the tuplestores. Yay!
>
> Thanks for that. ;-)
Sorry, I just can't resist references to Spaghetti Westerns.
https://en.
David Fetter wrote:
> Robert Haas wrote:
>> Kevin Grittner wrote:
> The good:
> - Generating the tuplestores. Yay!
Thanks for that. ;-)
> The bad:
> - Generating them exactly and only for AFTER triggers
The standard only allows them for AFTER triggers, and I'm not sure
what the sema
Robert Haas wrote:
> Kevin Grittner wrote:
> Can you describe what the standard syntax for the row variables
> is, as opposed to our syntax? Also, what's the standard syntax
> for the the transition relations?
If you want either (or both), the standard has you using a
REFERENCING clause right
Alvaro Herrera wrote:
> Kevin Grittner wrote:
> TRUNCATE triggers shouldn't have delta relations, that's for
> sure, or it'd completely negate the point of TRUNCATE triggers.
> I don't think we have any other event, do we? People who get
> delta relations for deleting all rows should be using DE
On Tue, Jun 17, 2014 at 04:07:55PM -0400, Robert Haas wrote:
> On Sat, Jun 14, 2014 at 7:56 PM, Kevin Grittner wrote:
> > I looked at the standard, and initially tried to implement the
> > standard syntax for this; however, it appeared that the reasons
> > given for not using standard syntax for t
On Sat, Jun 14, 2014 at 7:56 PM, Kevin Grittner wrote:
> I looked at the standard, and initially tried to implement the
> standard syntax for this; however, it appeared that the reasons
> given for not using standard syntax for the row variables also
> apply to the transition relations (the term u
Kevin Grittner wrote:
> Attached is a WIP patch for implementing the capture of delta
> relations for a DML statement, in the form of two tuplestores --
> one for the old versions and one for the new versions. In the
> short term it is intended to make these relations available in
> trigger functi
David Fetter wrote:
> Any chance we might be able to surface the old version for the
> case of UPDATE ... RETURNING?
Not as part of this patch.
Of course, once delta relations are available, who knows what
people might do with them. I have a hard time imagining exactly
how you would expose wha
On Sat, Jun 14, 2014 at 04:56:44PM -0700, Kevin Grittner wrote:
> Attached is a WIP patch for implementing the capture of delta
> relations for a DML statement, in the form of two tuplestores --
> one for the old versions and one for the new versions.
Thanks!
Any chance we might be able to surfac
101 - 146 of 146 matches
Mail list logo
