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
33 matches
Mail list logo
