Justin Pryzby wrote:
> I'm interested in testing this patch, however there's a lot of internals to
> digest.
>
> Are there any documentation updates or regression tests to add ?
I'm not sure if user documentation should be changed unless a new GUC or
statistics information is added. As for regr
On Sat, Sep 26, 2020 at 09:59:17PM -0500, Justin Pryzby wrote:
> I'm interested in testing this patch, however there's a lot of internals to
> digest.
Even with that, the thread has been waiting on author for a couple of
weeks now, so I have marke dthe entry as RwF.
--
Michael
signature.asc
Desc
On Fri, Jun 05, 2020 at 05:16:43PM +0200, Antonin Houska wrote:
> Antonin Houska wrote:
>
> > In general, the checks are significantly faster if there are many rows to
> > process, and a bit slower when we only need to check a single row.
>
> Attached is a new version that uses the existing simp
Hi,
I was looking at this patch with Corey during a patch-review session. So
these are basically our "combined" comments.
On 2020-06-05 17:16:43 +0200, Antonin Houska wrote:
> From 6c1cb8ae7fbf0a8122d8c6637c61b9915bc57223 Mon Sep 17 00:00:00 2001
> From: Antonin Houska
> Date: Fri, 5 Jun 2020 1
Hi,
On 2020-04-28 10:44:58 -0400, Tom Lane wrote:
> Stephen Frost writes:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> As you say, perhaps there's room for both things, but also as you say,
> >> it's not obvious how to decide intelligently between them.
>
> > The single-row case seems pr
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> As you say, perhaps there's room for both things, but also as you say,
>> it's not obvious how to decide intelligently between them.
> The single-row case seems pretty clear and also seems common enough that
> it'd be worth p
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Apr 23, 2020 at 10:35 AM Tom Lane wrote:
> > I think we're failing to communicate here. I agree that if the goal
> > is simply to re-implement what the RI triggers currently do --- that
> > is, retail one-row-at-a-time checks ---
On Thu, Apr 23, 2020 at 10:35 AM Tom Lane wrote:
> I think we're failing to communicate here. I agree that if the goal
> is simply to re-implement what the RI triggers currently do --- that
> is, retail one-row-at-a-time checks --- then we could probably dispense
> with all the parser/planner/exe
On Thu, Apr 23, 2020 at 2:18 AM Alvaro Herrera wrote:
> On 2020-Apr-22, Andres Freund wrote:
> > I assume that with constructing plans "manually" you don't mean to
> > create a plan tree, but to invoke parser/planner directly? I think
> > that'd likely be better than going through SPI, and there's
Robert Haas writes:
> On Wed, Apr 22, 2020 at 6:40 PM Tom Lane wrote:
>> But it's not entirely clear to me that we know the best plan for a
>> statement-level RI action with sufficient certainty to go that way.
> Well, I guess I'd naively think we want an index scan on a plain
> table. It is bar
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Apr 22, 2020 at 6:40 PM Tom Lane wrote:
> > But it's not entirely clear to me that we know the best plan for a
> > statement-level RI action with sufficient certainty to go that way.
> > Is it really the case that the plan would no
čt 23. 4. 2020 v 8:28 odesílatel Antonin Houska napsal:
> Pavel Stehule wrote:
>
> > čt 23. 4. 2020 v 7:06 odesílatel Antonin Houska napsal:
> >
> > Tom Lane wrote:
> >
> > > But it's not entirely clear to me that we know the best plan for a
> > > statement-level RI action with sufficient c
Pavel Stehule wrote:
> čt 23. 4. 2020 v 7:06 odesílatel Antonin Houska napsal:
>
> Tom Lane wrote:
>
> > But it's not entirely clear to me that we know the best plan for a
> > statement-level RI action with sufficient certainty to go that way.
> > Is it really the case that the plan would
čt 23. 4. 2020 v 7:06 odesílatel Antonin Houska napsal:
> Tom Lane wrote:
>
> > Robert Haas writes:
> > > Right -- the idea I was talking about was to create a Plan tree
> > > without using the main planner. So it wouldn't bother costing an index
> > > scan on each index, and a sequential scan,
Tom Lane wrote:
> Robert Haas writes:
> > Right -- the idea I was talking about was to create a Plan tree
> > without using the main planner. So it wouldn't bother costing an index
> > scan on each index, and a sequential scan, on the target table - it
> > would just make an index scan plan, or
On Wed, Apr 22, 2020 at 6:40 PM Tom Lane wrote:
> But it's not entirely clear to me that we know the best plan for a
> statement-level RI action with sufficient certainty to go that way.
> Is it really the case that the plan would not vary based on how
> many tuples there are to check, for example
Robert Haas writes:
> Right -- the idea I was talking about was to create a Plan tree
> without using the main planner. So it wouldn't bother costing an index
> scan on each index, and a sequential scan, on the target table - it
> would just make an index scan plan, or maybe an index path that it
On Wed, Apr 22, 2020 at 2:36 PM Andres Freund wrote:
> > If it's any consolation, I had the same idea very recently while
> > chatting with Amit Langote. Maybe it's a bad idea, but you're not the
> > only one who had it. :-)
>
> That seems extremely hard, given our current infrastructure. I think
On Wed, Apr 22, 2020 at 2:36 PM Andres Freund wrote:
> Hi,
>
> On 2020-04-22 13:46:22 -0400, Robert Haas wrote:
> > On Wed, Apr 22, 2020 at 1:18 PM Alvaro Herrera
> wrote:
> > > Well, I was actually thinking in building ready-made execution trees,
> > > bypassing the planner altogether. But app
Hi,
On 2020-04-08 13:55:55 -0400, Corey Huinker wrote:
> In doing my initial attempt, the feedback I was getting was that the people
> who truly understood the RI checks fell into the following groups:
> 1. people who wanted to remove the SPI calls from the triggers
> 2. people who wanted to compl
Hi,
On 2020-04-22 13:46:22 -0400, Robert Haas wrote:
> On Wed, Apr 22, 2020 at 1:18 PM Alvaro Herrera
> wrote:
> > Well, I was actually thinking in building ready-made execution trees,
> > bypassing the planner altogether. But apparently no one thinks that
> > this is a good idea, and we don't
Hi,
On 2020-04-22 13:18:06 -0400, Alvaro Herrera wrote:
> > But honestly, my gut feeling is that for a lot of cases it'd be best
> > just bypass parser, planner *and* executor. And just do manual
> > systable_beginscan() style checks. For most cases we exactly know what
> > plan shape we expect, a
On Wed, Apr 22, 2020 at 1:18 PM Alvaro Herrera wrote:
> Well, I was actually thinking in building ready-made execution trees,
> bypassing the planner altogether. But apparently no one thinks that
> this is a good idea, and we don't have any code that does that already,
> so maybe it's not a great
On 2020-Apr-22, Andres Freund wrote:
> I assume that with constructing plans "manually" you don't mean to
> create a plan tree, but to invoke parser/planner directly? I think
> that'd likely be better than going through SPI, and there's precedent
> too.
Well, I was actually thinking in building r
Hi,
On 2020-04-21 16:14:53 -0400, Tom Lane wrote:
> AFAIK, we do not have any code besides the planner that is capable of
> building a plan tree at all, and I'd be pretty hesitant to try to create
> such; those things are complicated.
I suspect what was meant was not to create the plan tree direc
Hi,
On 2020-04-21 11:34:54 -0400, Alvaro Herrera wrote:
> On 2020-Apr-20, Corey Huinker wrote:
>
> > > I can imagine removal of the SPI from the current implementation (and
> > > constructing the plans "manually"), but note that the queries I use in my
> > > patch are no longer that trivial. So t
Alvaro Herrera writes:
> I do wonder if the RI stuff would actually end up being faster without
> SPI. If not, we'd only end up writing more code to do the same thing.
> Now that tables can be partitioned, it is much more of a pain than when
> only regular tables could be supported. Obviously wi
On 2020-Apr-20, Corey Huinker wrote:
> > I can imagine removal of the SPI from the current implementation (and
> > constructing the plans "manually"), but note that the queries I use in my
> > patch are no longer that trivial. So the SPI makes sense to me because it
> > ensures regular query plann
>
> I can imagine removal of the SPI from the current implementation (and
> constructing the plans "manually"), but note that the queries I use in my
> patch are no longer that trivial. So the SPI makes sense to me because it
> ensures regular query planning.
>
As an intermediate step, in the case
Corey Huinker wrote:
> These numbers are very promising, and much more in line with my initial
> expectations. Obviously the impact on single-row DML is of major concern,
> though.
Yes, I agree.
> In doing my initial attempt, the feedback I was getting was that the people
> who truly understood
Pavel Stehule wrote:
>> st 8. 4. 2020 v 18:36 odesílatel Antonin Houska napsal:
>
>> Some performance comparisons are below. (Besides the execution time, please
>> note the difference in the number of trigger function executions.) In
>> general,
>> the checks are significantly faster if the
On Wed, Apr 8, 2020 at 1:06 PM Pavel Stehule
wrote:
>
>
> st 8. 4. 2020 v 18:36 odesílatel Antonin Houska napsal:
>
>> After having reviewed [1] more than a year ago (the problem I found was
>> that
>> the transient table is not available for deferred constraints), I've
>> tried to
>> implement
st 8. 4. 2020 v 18:36 odesílatel Antonin Houska napsal:
> After having reviewed [1] more than a year ago (the problem I found was
> that
> the transient table is not available for deferred constraints), I've tried
> to
> implement the same in an alternative way. The RI triggers still work as row
After having reviewed [1] more than a year ago (the problem I found was that
the transient table is not available for deferred constraints), I've tried to
implement the same in an alternative way. The RI triggers still work as row
level triggers, but if multiple events of the same kind appear in th
34 matches
Mail list logo
