On Tue, Oct 13, 2020 at 3:48 PM Amit Langote
wrote:
> On Thu, Oct 8, 2020 at 8:25 PM Ashutosh Bapat
> wrote:
> > On Wed, Oct 7, 2020 at 7:00 PM Andy Fan
> wrote:
> > > I can understand Robert's idea now, he intended to resolve both the
> > > "initial-partition-prune" case and "runtime partitio
On Thu, Oct 8, 2020 at 8:25 PM Ashutosh Bapat
wrote:
> On Wed, Oct 7, 2020 at 7:00 PM Andy Fan wrote:
> > I can understand Robert's idea now, he intended to resolve both the
> > "initial-partition-prune" case and "runtime partition prune" case while I
> > always think
> > about the former case
On Mon, Oct 12, 2020 at 5:48 PM Ashutosh Bapat
wrote:
> On Mon, Oct 12, 2020 at 7:59 AM Andy Fan wrote:
>
> >
> > Sorry for the late reply! Suppose we have partition defined like this:
> > p
> > - p1
> > - p2
> >
> > When you talk about "the statistics from the partitioned table", do you
> > me
On Mon, Oct 12, 2020 at 7:59 AM Andy Fan wrote:
>
> Sorry for the late reply! Suppose we have partition defined like this:
> p
> - p1
> - p2
>
> When you talk about "the statistics from the partitioned table", do you
> mean the statistics from p or p1/p2? I just confirmed there is no statistic
Hi Ashutosh:
On Thu, Oct 8, 2020 at 7:25 PM Ashutosh Bapat
wrote:
> On Wed, Oct 7, 2020 at 7:00 PM Andy Fan wrote:
> >
> >
> >
> > On Wed, Oct 7, 2020 at 5:05 PM Andy Fan
> wrote:
> >>
> >>
> >>
> >> On Sun, Oct 4, 2020 at 3:10 PM Andy Fan
> wrote:
>
>
>
> Now, in my exper
On Wed, Oct 7, 2020 at 7:00 PM Andy Fan wrote:
>
>
>
> On Wed, Oct 7, 2020 at 5:05 PM Andy Fan wrote:
>>
>>
>>
>> On Sun, Oct 4, 2020 at 3:10 PM Andy Fan wrote:
Now, in my experience, the current system for custom plans vs. generic
plans doesn't approach the problem in t
On Wed, Oct 7, 2020 at 5:05 PM Andy Fan wrote:
>
>
> On Sun, Oct 4, 2020 at 3:10 PM Andy Fan wrote:
>
>>
>>>
>>> Now, in my experience, the current system for custom plans vs. generic
>>> plans doesn't approach the problem in this way at all, and in my
>>> experience that results in some pretty
On Sun, Oct 4, 2020 at 3:10 PM Andy Fan wrote:
>
>>
>> Now, in my experience, the current system for custom plans vs. generic
>> plans doesn't approach the problem in this way at all, and in my
>> experience that results in some pretty terrible behavior. It will do
>> things like form a custom p
>
>
>
> Now, in my experience, the current system for custom plans vs. generic
> plans doesn't approach the problem in this way at all, and in my
> experience that results in some pretty terrible behavior. It will do
> things like form a custom plan every time because the estimated cost
> of the c
On Wed, May 29, 2019 at 6:02 PM Tom Lane wrote:
> Well, it *is* a problem. The whole point of this discussion I think is
> to try to get better information "by default" for routine bug reports.
> So if those come from production servers without debug symbols, which
> I believe will be the usual c
Robert Haas writes:
> On Fri, May 24, 2019 at 12:09 PM Tom Lane wrote:
>> Is it actually better? The basic problem with backtrace() is that it
>> only knows about global functions, and so reports call sites in static
>> functions as if they were in whatever global function physically precedes
>>
On Fri, May 24, 2019 at 12:09 PM Tom Lane wrote:
> Is it actually better? The basic problem with backtrace() is that it
> only knows about global functions, and so reports call sites in static
> functions as if they were in whatever global function physically precedes
> the static one. I think d
Hi,
On 2019-05-25 00:42:39 +0200, Tomas Vondra wrote:
> On Fri, May 24, 2019 at 09:24:28AM -0700, Andres Freund wrote:
> > On 2019-05-24 12:08:57 -0400, Tom Lane wrote:
> > > Andres Freund writes:
> > > The basic problem with backtrace() is that it
> > > only knows about global functions, and so
On Fri, May 24, 2019 at 09:24:28AM -0700, Andres Freund wrote:
Hi,
On 2019-05-24 12:08:57 -0400, Tom Lane wrote:
Andres Freund writes:
> On 2019-05-24 11:34:58 -0400, Tom Lane wrote:
>> Hmm, after some digging in the archives, the closest thing I can find
>> is this thread:
>>
https://www.pos
Hi,
On 2019-05-24 12:08:57 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-05-24 11:34:58 -0400, Tom Lane wrote:
> >> Hmm, after some digging in the archives, the closest thing I can find
> >> is this thread:
> >> https://www.postgresql.org/message-id/flat/CAMsr%2BYGL%2ByfWE%3DJvbUbnpW
Andres Freund writes:
> On 2019-05-24 11:34:58 -0400, Tom Lane wrote:
>> Hmm, after some digging in the archives, the closest thing I can find
>> is this thread:
>> https://www.postgresql.org/message-id/flat/CAMsr%2BYGL%2ByfWE%3DJvbUbnpWtrRZNey7hJ07%2BzT4bYJdVp4Szdrg%40mail.gmail.com
>> where we d
Hi,
On 2019-05-24 11:34:58 -0400, Tom Lane wrote:
> I wrote:
> > Peter Eisentraut writes:
> >> What do people think about adding something like this errbacktrace()
> >> from Álvaro's patch to core PostgreSQL?
>
> > I think we did discuss it right after that, or somewhere nearby, and
> > conclude
I wrote:
> Peter Eisentraut writes:
>> What do people think about adding something like this errbacktrace()
>> from Álvaro's patch to core PostgreSQL?
> I think we did discuss it right after that, or somewhere nearby, and
> concluded that the output is so imprecise that it's not really going
> to
Peter Eisentraut writes:
> On 2018-04-10 23:32, Alvaro Herrera wrote:
>> To figure out, I used the attached patch (not intended for application)
>> to add a backtrace to each log message, plus a couple of accusatory
>> elog() calls in relation_open and ExecSetupPartitionPruneState.
> What do peop
On 2018-04-10 23:32, Alvaro Herrera wrote:
> To figure out, I used the attached patch (not intended for application)
> to add a backtrace to each log message, plus a couple of accusatory
> elog() calls in relation_open and ExecSetupPartitionPruneState.
What do people think about adding something l
On 25 April 2018 at 05:10, Alvaro Herrera wrote:
> Pushed. Thanks!
Thanks!
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 25 April 2018 at 06:21, Alvaro Herrera wrote:
> Andres Freund wrote:
>
>> What I wonder, after skimming this change, is where the relevant
>> expression context is reset? That's not really related to this change
>> but the wider thread, I just noticed it while looking at this.
>
> Do you mean
Andres Freund wrote:
> What I wonder, after skimming this change, is where the relevant
> expression context is reset? That's not really related to this change
> but the wider thread, I just noticed it while looking at this.
Do you mean ResetExprContext? We use the plan's context, so it should
On 2018-04-19 12:04:35 +1200, David Rowley wrote:
> On 19 April 2018 at 03:13, Robert Haas wrote:
> > 10% is more than a "slight" improvement, I'd say! It's certainly got
> > to be worth avoiding the repeated calls to ExecInitExpr, whatever we
> > do about the memory contexts.
Yea, that seems im
Pushed. Thanks!
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Amit Langote wrote:
> That's neat! Definitely agree that we should call ExecInitExpr just once
> here. The patch looks good too, except the long line.
How about this as a small tweak? Determine the array index using a
macro, which serves as documentation.
--
Álvaro Herrerahtt
Anybody wanna argue against pushing this patch now? I'm inclined to
push it on the grounds of being closure for already committed work, but
there are possible arguments about this being new development after
feature freeze.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL
Hi David.
On 2018/04/19 9:04, David Rowley wrote:
> On 19 April 2018 at 03:13, Robert Haas wrote:
>> On Mon, Apr 16, 2018 at 10:46 PM, David Rowley
>> wrote:
>>> The patch does happen to improve performance slightly, but that is
>>> most likely due to the caching of the ExprStates rather than th
On 19 April 2018 at 12:04, David Rowley wrote:
> insert into p select x,x from generate_Series(1,1000) x;
> insert into t1 select x from generate_series(1,1000) x;
Correction. These were meant to read:
insert into p select x,x from generate_Series(1,1000) x;
insert into t1 select x from gene
On 19 April 2018 at 03:13, Robert Haas wrote:
> On Mon, Apr 16, 2018 at 10:46 PM, David Rowley
> wrote:
>> I did go and start working on a patch to test how possible this would
>> be and came up with the attached. I've left a stray
>> MemoryContextStatsDetail call in there which does indicate tha
On Mon, Apr 16, 2018 at 10:46 PM, David Rowley
wrote:
> I did go and start working on a patch to test how possible this would
> be and came up with the attached. I've left a stray
> MemoryContextStatsDetail call in there which does indicate that
> something is not being freed. I'm just not sure wh
On 17 April 2018 at 14:33, Alvaro Herrera wrote:
> David Rowley wrote:
>
>> For a while, during my review of the faster partition pruning patch I
>> was asking Amit to add pfree() calls in various places for this exact
>> reason, but in the end, I gave up and decided it was easier to just
>> creat
David Rowley wrote:
> For a while, during my review of the faster partition pruning patch I
> was asking Amit to add pfree() calls in various places for this exact
> reason, but in the end, I gave up and decided it was easier to just
> create a new memory context to call the planner function from.
On 14 April 2018 at 05:04, Robert Haas wrote:
> But I wonder why it's the executor's job to clean up after the
> planner, instead of adjusting the relevant planner functions to avoid
> leaking memory?
It might be possible, but it might also be risky and difficult.
For a while, during my review o
On Thu, Apr 12, 2018 at 6:01 PM, David Rowley
wrote:
> On 13 April 2018 at 04:57, Robert Haas wrote:
>> BTW, looking at ExecSetupPartitionPruneState:
>>
>> /*
>> * Create a sub memory context which we'll use when making calls to
>> the
>> * query planner's function to d
On 2018/04/13 14:48, Amit Langote wrote:
> On 2018/04/13 14:38, Amit Langote wrote:
>> About the specific relation_open(.., NoLock) under question, I think there
>> might be a way to address this by opening the tables with the appropriate
>> lock mode in partitioned_rels list in ExecLockNonleafAppe
On 2018/04/13 14:38, Amit Langote wrote:
> About the specific relation_open(.., NoLock) under question, I think there
> might be a way to address this by opening the tables with the appropriate
> lock mode in partitioned_rels list in ExecLockNonleafAppendTables
That may have sounded a bit confusin
On 2018/04/13 1:57, Robert Haas wrote:
>> It might be possible to do something better in each module by keeping
>> an array indexed by RTI which have each entry NULL initially then on
>> first relation_open set the element in the array to that pointer.
>
> I'm not sure that makes a lot of sense in
On 13 April 2018 at 04:57, Robert Haas wrote:
> BTW, looking at ExecSetupPartitionPruneState:
>
> /*
> * Create a sub memory context which we'll use when making calls to
> the
> * query planner's function to determine which partitions will
> match. The
> * plan
On Thu, Apr 12, 2018 at 12:40 AM, David Rowley
wrote:
> I guess the problem there would be there's nothing to say that parse
> analysis will shortly be followed by a call to the planner, and a call
> to the planner does not mean the plan is about to be executed. So I
> don't think it would be poss
On 11 April 2018 at 09:32, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Mon, Apr 9, 2018 at 2:28 PM, Alvaro Herrera
>> wrote:
>
>> >> I don't get this. The executor surely had to (and did) open all of
>> >> the relations somewhere even before this patch.
>
>> > I was worried that this codin
On 2018/04/11 6:32, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Mon, Apr 9, 2018 at 2:28 PM, Alvaro Herrera
>> wrote:
>
I don't get this. The executor surely had to (and did) open all of
the relations somewhere even before this patch.
>
>>> I was worried that this coding could b
Robert Haas wrote:
> On Mon, Apr 9, 2018 at 2:28 PM, Alvaro Herrera
> wrote:
> >> I don't get this. The executor surely had to (and did) open all of
> >> the relations somewhere even before this patch.
> > I was worried that this coding could be seen as breaking modularity, or
> > trying to do
Robert Haas wrote:
> On Mon, Apr 9, 2018 at 2:28 PM, Alvaro Herrera
> wrote:
> > Robert Haas wrote:
> >> I don't get this. The executor surely had to (and did) open all of
> >> the relations somewhere even before this patch.
> >
> > I was worried that this coding could be seen as breaking modul
On Mon, Apr 9, 2018 at 2:28 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Sat, Apr 7, 2018 at 5:13 PM, Alvaro Herrera
>> wrote:
>> > I had reservations about a relation_open() in the new executor code. It
>> > seemed a bit odd; we don't have any other relation_open in the executor
>> > a
Robert Haas wrote:
> On Sat, Apr 7, 2018 at 5:13 PM, Alvaro Herrera
> wrote:
> > I had reservations about a relation_open() in the new executor code. It
> > seemed a bit odd; we don't have any other relation_open in the executor
> > anywhere. However, setting up the pruneinfo needs some stuff f
On Sat, Apr 7, 2018 at 5:13 PM, Alvaro Herrera wrote:
> I had reservations about a relation_open() in the new executor code. It
> seemed a bit odd; we don't have any other relation_open in the executor
> anywhere. However, setting up the pruneinfo needs some stuff from
> relcache that I don't se
On 8 April 2018 at 09:13, Alvaro Herrera wrote:
> I pushed this patch -- 0001, 0002 and 0003 only. I did not include
> anything from 0004 and 0005; I didn't even get to the point of reading
> them, so that I could focus on the first part.
Oh great! Thank you for working on this and pushing it, e
I pushed this patch -- 0001, 0002 and 0003 only. I did not include
anything from 0004 and 0005; I didn't even get to the point of reading
them, so that I could focus on the first part.
I did not find anything to complain about. I made a few adjustments and
asked David to supply a paragraph for p
Hi,
On 04/07/2018 04:45 AM, David Rowley wrote:
Ok, so I've gone and done this.
PartitionPruning has become PartitionPruneState
PartitionRelPruning has become PartitionPruningData
I've changed pointers to PartitionPruneStates to be named prunestate,
sometimes having the node prefix; as_, ma_,
David Rowley wrote:
> On 8 April 2018 at 01:18, Alvaro Herrera wrote:
> > Amit had it as "indexes" also in his original. I wanted to avoid using
> > the "indexes" word alone, whose meaning is so overloaded.
>
> hmm, good point.
>
> > How about this?
> > "... which are then executed to produce a
On 8 April 2018 at 01:18, Alvaro Herrera wrote:
> Amit had it as "indexes" also in his original. I wanted to avoid using
> the "indexes" word alone, whose meaning is so overloaded.
hmm, good point.
> How about this?
> "... which are then executed to produce a set of partitions (as indexes
> of
David Rowley wrote:
> It's not exactly wrong but:
>
> + * are turned into a set of "pruning steps", which are then executed to
> + * produce a set of RTIs of partitions whose bounds satisfy the constraints
> in
> + * the step. Partitions not in the set are said to have been pruned.
>
> It's on
On 8 April 2018 at 00:23, Alvaro Herrera wrote:
> I edited it as attached, to 1. avoid mentioning functionality that
> doesn't yet exist, and 2. avoid excessive internal detail (we want a
> high-level overview here), which from experience gets outdated pretty
> quickly.
It's not exactly wrong but
Amit Langote wrote:
> See if the attached makes it any better.
>
> Now I know we don't have the runtime pruning in yet, but since the
> proposed patch would extend its functionality I have included its
> description in the comment.
Thanks!
I edited it as attached, to 1. avoid mentioning functio
On Sat, Apr 7, 2018 at 1:58 PM, Amit Langote wrote:
> On Sat, Apr 7, 2018 at 1:31 PM, Andres Freund wrote:
>> I've not followed this thread/feature at all, but I don't find the
>> comments atop partprune.c even remotely sufficient. Unless there's an
>> README hidden or such hidden somewhere?
>
>
On 2018-04-07 16:58:01 +1200, David Rowley wrote:
> On 7 April 2018 at 16:31, Andres Freund wrote:
> > I've not followed this thread/feature at all, but I don't find the
> > comments atop partprune.c even remotely sufficient. Unless there's an
> > README hidden or such hidden somewhere?
>
> There
On Sat, Apr 7, 2018 at 1:58 PM, David Rowley
wrote:
> Probably if we need to explain more there about how pruning works then
> it should be a fixup patch to 9fdb675fc, no?
Yes, I just replied and working on a patch.
Thanks,
Amit
On Sat, Apr 7, 2018 at 1:31 PM, Andres Freund wrote:
> On 2018-04-07 13:26:51 +0900, Amit Langote wrote:
>> On Sat, Apr 7, 2018 at 11:26 AM, David Rowley
>> wrote:
>> > Everything else looks fine from my point of view.
>>
>> Me too, although I still think having struct names PartitionPruning
>> a
On 7 April 2018 at 16:31, Andres Freund wrote:
> I've not followed this thread/feature at all, but I don't find the
> comments atop partprune.c even remotely sufficient. Unless there's an
> README hidden or such hidden somewhere?
There's not a README file. The comments for partprune.c, do you wan
On 7 April 2018 at 16:26, Amit Langote wrote:
> Maybe, PartitionPruneState, because it parallels the
> PartitionPruneInfo that comes from the planner for every partitioned
> table in the tree.
I like that.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development,
On 2018-04-07 13:26:51 +0900, Amit Langote wrote:
> On Sat, Apr 7, 2018 at 11:26 AM, David Rowley
> wrote:
> > Everything else looks fine from my point of view.
>
> Me too, although I still think having struct names PartitionPruning
> and PartitionRelPruning is going to be a bit confusing. We s
On Sat, Apr 7, 2018 at 11:26 AM, David Rowley
wrote:
> Everything else looks fine from my point of view.
Me too, although I still think having struct names PartitionPruning
and PartitionRelPruning is going to be a bit confusing. We should
think about naming the latter to something else. I sugg
On 7 April 2018 at 12:03, David Rowley wrote:
> Continuing to read 0003 and 0004 now.
0003:
1. "setup" -> "set"
/* If run-time partition pruning is enabled, then setup that up now */
2. We should be able to get rid of as_noopscan and just have another
special negative value for as_whichplan.
On 7 April 2018 at 10:45, David Rowley wrote:
> I'm looking over the rebased patches now.
I've made a complete read of 0001 and 0002 so far.
Your rebase looks fine.
After the complete read, I only have the following comments:
0001:
1. missing "the" before "partition key":
* Extract Params ma
On 7 April 2018 at 09:29, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> I rebased this series on top of the committed version of the other patch.
>> Here's v22, with no other changes than rebasing. I did not include
>> 0005, though.
>
> Apologies, I forgot to "git add" one fixup for 0001.
000
Alvaro Herrera wrote:
> I rebased this series on top of the committed version of the other patch.
> Here's v22, with no other changes than rebasing. I did not include
> 0005, though.
Apologies, I forgot to "git add" one fixup for 0001.
--
Álvaro Herrerahttps://www.2ndQuadrant.co
Hi David,
On 2018/04/06 12:27, David Rowley wrote:
> (sending my reply in parts for concurrency)
>
> On 6 April 2018 at 14:39, Amit Langote wrote:
>> I think we can save some space here by not having the pointers stored
>> here. Instead of passing the pointer itself in the recursive calls to
>>
(sending my reply in parts for concurrency)
On 6 April 2018 at 14:39, Amit Langote wrote:
> I think we can save some space here by not having the pointers stored
> here. Instead of passing the pointer itself in the recursive calls to
> find_subplans_for_extparams_recurse, et al, just pass the en
Hi David.
On 2018/04/05 22:41, David Rowley wrote:
>> * make_partition_pruneinfo has a parameter resultRelations that's not used
>> anywhere
>
> It gets used in 0005.
>
> I guess I could only add it in 0005, but make_partition_pruneinfo is
> only used in 0003, so you could say the same about tha
Hi David,
First of all: Solid patch set with good documentation.
On 04/05/2018 09:41 AM, David Rowley wrote:
Seems mostly fair. I'm not a fan of using the term "unpruned" though.
I'll have a think. The "all" is meant in terms of what exists as
subnodes.
'included_parts' / 'excluded_parts' p
Hi Amit,
Thanks for having a look at this.
On 6 April 2018 at 00:54, Amit Langote wrote:
> I looked at it and here are my thoughts on it after having for the first
> time looked very closely at it.
>
> * Regarding PartitionPruneInfo:
>
> I think the names of the fields could be improved -- like
On 2018/04/05 12:14, Amit Langote wrote:
> I will post comments on your v19 later today.
I looked at it and here are my thoughts on it after having for the first
time looked very closely at it.
* Regarding PartitionPruneInfo:
I think the names of the fields could be improved -- like pruning_step
On 5 April 2018 at 15:14, Amit Langote wrote:
> On 2018/03/31 22:52, David Rowley wrote:
>> Initialising
>> Append/MergeAppend/ModifyTable nodes with fewer subnodes than were
>> originally planned did require a small change in explain.c in some
>> code that was assuming the subnode arrays were the
Hi David.
On 2018/03/31 22:52, David Rowley wrote:
> The attached patchset is based on Amit's v45 faster partition pruning [1].
>
> I've made a few changes since the v14 version. Since Amit's v45 patch
> now creates the partition pruning details in a data structure that can
> be copied from the p
Hi David,
On 04/03/2018 10:10 PM, David Rowley wrote:
The attached case doesn't trigger a generic plan, so basically all time is
spent in GetCachedPlan.
Yeah, there's still no resolution to the fact that a generic plan +
runtime pruning might be cheaper than a custom plan. The problem is
the
On 2018/04/04 16:04, David Rowley wrote:
> On 4 April 2018 at 18:27, Amit Langote wrote:
>> I'm not sure if we've yet discussed anything that'd be related to this on
>> the faster pruning thread.
>
> hmm, yeah, I didn't really explain the context, but the report was in [1]>
> [1]
> https://www.p
On 4 April 2018 at 18:27, Amit Langote wrote:
> On 2018/04/04 11:10, David Rowley wrote:
>> On 4 April 2018 at 05:44, Jesper Pedersen wrote:
>>> Also, I'm seeing a regression for check-world in
>>> src/test/regress/results/inherit.out
>>>
>>> ***
>>> *** 642,648
>>> ---
Hi David.
On 2018/04/04 11:10, David Rowley wrote:
> On 4 April 2018 at 05:44, Jesper Pedersen wrote:
>> Also, I'm seeing a regression for check-world in
>> src/test/regress/results/inherit.out
>>
>> ***
>> *** 642,648
>> -+---+---+-
>>mlparted_tab_p
Hi David,
On Wed, Apr 4, 2018 at 7:57 AM, David Rowley
wrote:
> On 4 April 2018 at 05:50, Beena Emerson wrote:
>> With Amit's v46 patch, the following query in partition_prune was
>> crashing during make check.
>> explain (analyze, costs off, summary off, timing off) execute ab_q1 (2, 2,
>> 3)
On 4 April 2018 at 14:10, David Rowley wrote:
> On 4 April 2018 at 05:44, Jesper Pedersen wrote:
>> The attached case doesn't trigger a generic plan, so basically all time is
>> spent in GetCachedPlan.
>
> Yeah, there's still no resolution to the fact that a generic plan +
> runtime pruning might
On 4 April 2018 at 05:50, Beena Emerson wrote:
> With Amit's v46 patch, the following query in partition_prune was
> crashing during make check.
> explain (analyze, costs off, summary off, timing off) execute ab_q1 (2, 2, 3);
Hi Beena,
Thanks for looking.
Does it work correctly if you apply [1
On 4 April 2018 at 05:44, Jesper Pedersen wrote:
> I have tested this together with Amit's v46 patch.
Thanks for testing this.
> The attached case doesn't trigger a generic plan, so basically all time is
> spent in GetCachedPlan.
Yeah, there's still no resolution to the fact that a generic plan
Hello,
On Tue, Apr 3, 2018 at 11:14 PM, Jesper Pedersen
wrote:
> Hi David,
>
> On 03/31/2018 09:52 AM, David Rowley wrote:
>>
>> I've attached a new version of the patch. I'm now at v18 after having
>> some versions of the patch that I didn't release which were based on
>> various versions of Am
Hi David,
On 03/31/2018 09:52 AM, David Rowley wrote:
I've attached a new version of the patch. I'm now at v18 after having
some versions of the patch that I didn't release which were based on
various versions of Amit's faster partition pruning patch.
Thank you for the updated patch set !
I
David Rowley wrote:
> To put the new patch to the test, I tried pgbench -S -M prepared -s
> 100 with and without having modified pgbench_accounts to separate into
> 10 RANGE partitions of equal size.
>
> A non-partitioned table was getting 12503 TPS.
> With partitioned tables, the old version of
Hi David,
On 03/01/2018 08:29 PM, David Rowley wrote:
0004 fails "make check-world" due to
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 670; 1259 49954 TABLE
boolp_f jpedersen
pg_restore: [archiver (db)] could not execute query: ERROR:
On 2 March 2018 at 07:17, Jesper Pedersen wrote:
> A small typo in 0001:
>
> + * leftmost_ons_pos[x] gives the bit number (0-7) of the leftmost one bit
> in a
>
> ..."_one_"...
Oops. I'll fix that.
> 0004 fails "make check-world" due to
>
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
Hi David,
On 03/01/2018 08:04 AM, David Rowley wrote:
I've also split the patch out a bit more into logical parts in the
hope it makes things easier to review.
A small typo in 0001:
+ * leftmost_ons_pos[x] gives the bit number (0-7) of the leftmost one
bit in a
..."_one_"...
0004 fails "
On 27 February 2018 at 22:39, Amit Langote
wrote:
> I've incorporated portions of 0002 and 0003 into my patch on the other
> thread (v34) posted at [1]. That is, mostly the changes around handling
> OR clauses and interface changes resulting from it.
Thanks. I was just in the middle of swapping
On 2018/02/23 20:40, David Rowley wrote:
> On 23 February 2018 at 04:11, Jesper Pedersen
> wrote:
>> Are UPDATE and DELETE suppose to be supported ?
>
> To be honest, I had not even considered those. Without looking in
> detail I imagine it may be possible to allow this simply by setting
> the Ap
(Sorry, I had mistakenly replied only to Simon on Friday)
On Fri, Feb 23, 2018 at 9:04 PM, Simon Riggs wrote:
> On 23 February 2018 at 11:40, David Rowley
> wrote:
>> On 23 February 2018 at 04:11, Jesper Pedersen
>> wrote:
>>> Are UPDATE and DELETE suppose to be supported ?
>>
>> To be honest,
On 23 February 2018 at 11:40, David Rowley wrote:
> On 23 February 2018 at 04:11, Jesper Pedersen
> wrote:
>> Are UPDATE and DELETE suppose to be supported ?
>
> To be honest, I had not even considered those.
I can say that I had considered those. Handling of UPDATE and DELETE
with partitions is
On 23 February 2018 at 04:11, Jesper Pedersen
wrote:
> Are UPDATE and DELETE suppose to be supported ?
To be honest, I had not even considered those. Without looking in
detail I imagine it may be possible to allow this simply by setting
the AppendPath->trypartitionprune in the correct cases in th
Hi David.
On 2018/02/23 0:11, David Rowley wrote:
> On 23 February 2018 at 01:15, David Rowley
> wrote:
>> One problem that I'm facing now is down to the way I'm gathering the
>> ParamIds that match the partkeys. As you'll see from the patch I've
>> added a 'paramids' field to PartitionPruneCont
On 23 February 2018 at 01:15, David Rowley wrote:
> One problem that I'm facing now is down to the way I'm gathering the
> ParamIds that match the partkeys. As you'll see from the patch I've
> added a 'paramids' field to PartitionPruneContext and I'm populating
> this when the clauses are being pr
Hi David,
On 02/21/2018 04:06 AM, David Rowley wrote:
I've attached v11 of the patch.
Are UPDATE and DELETE suppose to be supported ?
With
-- test.sql --
CREATE TABLE test (a integer NOT NULL, b integer) PARTITION BY HASH(a);
CREATE TABLE test_p00 PARTITION OF test FOR VALUES WITH (MODULUS
On 22 February 2018 at 22:31, Amit Langote
wrote:
> Some comments:
Hi Amit,
Thanks for looking at this. I'll work through your comments and
produce a patch sometime in the near future.
One problem that I'm facing now is down to the way I'm gathering the
ParamIds that match the partkeys. As you'
Hi David.
On 2018/02/21 18:06, David Rowley wrote:
> Other things I don't particularly like about the current patch are how
> I had to construct the partition key expressions in
> set_valid_runtime_subplans_recurse(). This pretty much uses code
> borrowed from set_baserel_partition_key_exprs(). On
On 21 February 2018 at 22:45, Rajkumar Raghuwanshi
wrote:
> select count(*) from prt1 x where (x.a,x.b) in (select t1.a,t2.b from prt1
> t1,prt2 t2 where t1.a=t2.b)
> and (x.c) in (select t3.c from plt1 t3,plt2 t4 where t3.c=t4.c);
Thanks for the test case.
It seems like the x.c Param for some r
1 - 100 of 170 matches
Mail list logo
