Thank you for committing.
At Fri, 28 Mar 2014 11:50:56 -0400, Tom Lane wrote in
<21426.1396021...@sss.pgh.pa.us>
tgl> Kyotaro HORIGUCHI writes:
tgl> > Hello. Attached is the 2nd version of 'pushdown in UNION ALL on
tgl> > partitioned tables' patch type 1 - fix in equiv-member version.
tgl>
tgl
Kyotaro HORIGUCHI writes:
> Hello. Attached is the 2nd version of 'pushdown in UNION ALL on
> partitioned tables' patch type 1 - fix in equiv-member version.
Committed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Hello. Attached is the 2nd version of 'pushdown in UNION ALL on
partitioned tables' patch type 1 - fix in equiv-member version.
As far as I can see, I have found no problem on the original
Tom's patch. I have no annoyance of modifying inh flag and so
with this.
At Tue, 04 Mar 2014 18:57:56 +090
Kyotaro HORIGUCHI writes:
>> ec_relids has never included child relids.
> relation.h says that,
> |Relids ec_relids; /* all relids appearing in ec_members */
> ...
> |Relids em_relids; /* all relids appearing in em_expr */
Ah. Those comments could use improvement, I guess.
Hello, I haven't look closer on their relationship.
> > Hello, I examined the your patch and it seemed reasonable, but I
> > have one question about this patch.
>
> > You made ec_relids differ to the union of all ec members'
> > em_relids. Is it right?
>
> ec_relids has never included child reli
Kyotaro HORIGUCHI writes:
> Hello, I examined the your patch and it seemed reasonable, but I
> have one question about this patch.
> You made ec_relids differ to the union of all ec members'
> em_relids. Is it right?
ec_relids has never included child relids.
regards, to
Hello, I examined the your patch and it seemed reasonable, but I
have one question about this patch.
You made ec_relids differ to the union of all ec members'
em_relids. Is it right?
At Mon, 03 Mar 2014 14:05:10 -0500, Tom Lane wrote
> Noah Misch writes:
> > If you are convinced that a sepa
Hello,
> > Unfortunately, RTE_SUBQUERY-es with their inh flag cleard might
> > cause something inconvenient in preprocess_minmax_aggregates()
> > and/or add_rtes_to_flat_rtable()..
>
> preprocess_minmax_aggregates() only cares about RTEs reachable from the join
> tree, and the appendrel parents m
Noah Misch writes:
> If you are convinced that a separate flattening pass is best, that suffices
> for me at this stage. Please submit the patch you have in mind, incorporating
> any improvements from the v7 patch that are relevant to both approaches.
I went back and re-read the original message
On Mon, Mar 03, 2014 at 07:01:09PM +0900, Kyotaro HORIGUCHI wrote:
> > > Yes, the old dumped version of typ2 patch did so. It flattened
> > > appendrel tree for the query prpoerly. Let me hear the reson you
> > > prefer to do so.
> >
> > Having reviewed my upthread reasoning for preferring one of
Hello,
> > Yes, the old dumped version of typ2 patch did so. It flattened
> > appendrel tree for the query prpoerly. Let me hear the reson you
> > prefer to do so.
>
> Having reviewed my upthread reasoning for preferring one of those two
> approaches over the other, it's a weak preference. They
On Fri, Feb 28, 2014 at 02:35:50PM +0900, Kyotaro HORIGUCHI wrote:
> At Thu, 27 Feb 2014 21:53:52 -0500, Noah Misch wrote
> > On Thu, Feb 27, 2014 at 05:33:47PM -0500, Tom Lane wrote:
> > > I wonder whether we should consider adding a pass to flatten any nested
> > > appendrels after we're done cre
Sorry, I did wrong test.
> > > Noah Misch writes:
> > > > If the attached patch version looks reasonable, I will commit it.
> > >
> > > The test case is completely bogus, as the query explained is significantly
> > > different from the query executed. I'm not sure whether you can just
> > > rem
Hello,
At Thu, 27 Feb 2014 21:53:52 -0500, Noah Misch wrote
> On Thu, Feb 27, 2014 at 05:33:47PM -0500, Tom Lane wrote:
> > Noah Misch writes:
> > > If the attached patch version looks reasonable, I will commit it.
> >
> > The test case is completely bogus, as the query explained is significantl
On Thu, Feb 27, 2014 at 05:33:47PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > If the attached patch version looks reasonable, I will commit it.
>
> The test case is completely bogus, as the query explained is significantly
> different from the query executed. I'm not sure whether you can ju
On Thu, Feb 27, 2014 at 05:47:16PM -0500, Tom Lane wrote:
> BTW, isn't the proposed change to the comments for adjust_appendrel_attrs
> just wrong? If it's correct, why doesn't the Assert(!IsA(node, SubLink))
> therein fire? (AFAICS, the existing comment is correct: we don't use
> this function u
BTW, isn't the proposed change to the comments for adjust_appendrel_attrs
just wrong? If it's correct, why doesn't the Assert(!IsA(node, SubLink))
therein fire? (AFAICS, the existing comment is correct: we don't use
this function until after expression preprocessing is complete.)
Noah Misch writes:
> If the attached patch version looks reasonable, I will commit it.
The test case is completely bogus, as the query explained is significantly
different from the query executed. I'm not sure whether you can just
remove the extra ORDER BY column without getting machine-dependen
On Thu, Feb 27, 2014 at 07:30:57PM +0900, Kyotaro HORIGUCHI wrote:
> Thank you for the labor for polishing this patch.
>
> I have no obvious objection at a glance on this new patch.
>
> I agree to commit this if you this is pertinent to commit except
> for the issue newly revealed by this patch.
Thank you for the labor for polishing this patch.
I have no obvious objection at a glance on this new patch.
I agree to commit this if you this is pertinent to commit except
for the issue newly revealed by this patch. Though could you let
me have some more time to examine this by myself and fully
On Mon, Feb 03, 2014 at 07:36:22PM +0900, Kyotaro HORIGUCHI wrote:
> > > create table parent (a int, b int);
> > > create table child () inherits (parent);
> > > insert into parent values (1,10);
> > > insert into child values (2,20);
> > > select a, b from parent union all select a, b from child;
Hello, The attached file
"unionall_inh_idx_typ3_v6_20140203.patch" is the new version of
this patch fixed the 'whole-row-var' bug.
First of all, on second thought about this,
> > create table parent (a int, b int);
> > create table child () inherits (parent);
> > insert into parent values (1,10)
Hello,
> No hurry.
Thanks.
> > > > The attached two patches are rebased to current 9.4dev HEAD and
> > > > make check at the topmost directory and src/test/isolation are
> > > > passed without error. One bug was found and fixed on the way. It
> > > > was an assertion failure caused by probably
On Tue, Jan 28, 2014 at 06:53:32PM +0900, Kyotaro HORIGUCHI wrote:
> Hello, Thank you, and I' sorry to have kept you waiting.
No hurry.
> > > The attached two patches are rebased to current 9.4dev HEAD and
> > > make check at the topmost directory and src/test/isolation are
> > > passed without e
Hello, Thank you, and I' sorry to have kept you waiting.
> Let's focus on type 3; Tom and I both found it most promising.
Agreed.
> > The attached two patches are rebased to current 9.4dev HEAD and
> > make check at the topmost directory and src/test/isolation are
> > passed without error. One b
On Tue, Jan 14, 2014 at 06:04:47PM +0900, Kyotaro HORIGUCHI wrote:
> I proposed 3 types of solution but the one of them - tweaking
> Equivalence Class (Type 1)- was dismissed because of
> inappropriate manipulation on Equivalence Class. The rest do
> essentially the same thing - flattening appendre
This is cont'd from previous CF3.
You'll see the overview and the discussion since in the thread
begins from there. The issue ramains as of current 9.4dev head.
http://www.postgresql.org/message-id/20131024.193953.233464126.horiguchi.kyot...@lab.ntt.co.jp
The issue in brief is that UNION ALL on
Kyotaro HORIGUCHI writes:
> My PATCH-1 which make them in the third group forcibly
> classified as 'parent' instead of 'child' as before therefore
> makes 'broken' ec member?
If you marked child entries as non-child, then yes, it's broken.
The definition of a regular EC member is that it's alwa
Hello,
> I'll soon come up with regress for the patch 3, 4.
New version patches added with regression tests are attached.
I'll show you pulling-up-in-expand_inherited_rtentry version
later.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/optimizer/plan/
Thank you.
I'll soon come up with regress for the patch 3, 4.
=
> > See commit dd4134ea, which added that text. IIRC, the key point is that
> > among "real" EC members, there will never be duplicates: a Var "x.y"
> > for instance cannot appear in two different ECs, because we'd have merged
>
On Sat, Nov 23, 2013 at 01:35:32PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > I'm unclear on the key ideas behind distinguishing em_is_child members from
> > ordinary EC members. src/backend/optimizer/README says "These members are
> > *not* full-fledged members of the EquivalenceClass and d
Noah Misch writes:
> I'm unclear on the key ideas behind distinguishing em_is_child members from
> ordinary EC members. src/backend/optimizer/README says "These members are
> *not* full-fledged members of the EquivalenceClass and do not affect the
> class's overall properties at all." Is that an
On Thu, Oct 24, 2013 at 07:39:53PM +0900, Kyotaro HORIGUCHI wrote:
> 1. Observed symptom
>
> As you know, UNION ALL accompanied with ORDER BY uses indexes if
> available.
> So do simple queries on partitioned (inheritance) tables.
> Nevertheless, UNION ALL on partitioned tables doesn't. This is
Umm. I might be working on a bit unstable place..
> Your patch doesn't apply anymore. Please rebase it.
Thank you. I rebased all patches to current master.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/optimizer/path/equivclass.c b/src/backend/optimize
On 10/29/13, 11:05 PM, Kyotaro HORIGUCHI wrote:
> Hello,
>
>> Please add your patches to the currently-open CommitFest so that we
>> don't lose track of them.
>>
>> https://commitfest.postgresql.org/action/commitfest_view/open
>>
>> I'm not sure which approach to this problem is best, but I agree
Hello,
> Please add your patches to the currently-open CommitFest so that we
> don't lose track of them.
>
> https://commitfest.postgresql.org/action/commitfest_view/open
>
> I'm not sure which approach to this problem is best, but I agree that
> it is worth solving.
Thank you, I've regsitered
On Thu, Oct 24, 2013 at 6:39 AM, Kyotaro HORIGUCHI
wrote:
> Hello, Sorry that it's been a while..
>
> 1. Observed symptom
>
> As you know, UNION ALL accompanied with ORDER BY uses indexes if
> available.
>
>> uniontest=# EXPLAIN SELECT * FROM c11 UNION ALL SELECT * FROM c12 ORDER BY a;
>>
Hello, Sorry that it's been a while..
1. Observed symptom
As you know, UNION ALL accompanied with ORDER BY uses indexes if
available.
> uniontest=# EXPLAIN SELECT * FROM c11 UNION ALL SELECT * FROM c12 ORDER BY a;
>QUERY PLAN
>
38 matches
Mail list logo
