Hello. Thank you for the attentive comments.
> I wrote:
> > I still think this stuff mostly needs to be thrown away and rewritten
> > in Path-creation style, but that's a long-term project. In the meantime
> > this seems like a relatively small increment of complexity, so maybe it's
> > worth app
I wrote:
> I still think this stuff mostly needs to be thrown away and rewritten
> in Path-creation style, but that's a long-term project. In the meantime
> this seems like a relatively small increment of complexity, so maybe it's
> worth applying. I'm concerned about the method for building a ne
I wrote:
> However, it's not clear to me that this is worth the trouble. The
> DISTINCT would act as an optimization fence preventing the subquery from
> being flattened any further, so it doesn't seem like there would be any
> global benefit just because it now contains a simple appendrel rather
Andres Freund writes:
> On 2014-01-14 18:10:40 +0900, Kyotaro HORIGUCHI wrote:
>> This patch flattens UNION likewise currently did for UNION ALL.
> I haven't really followed this topic, so please excuse my ignorance.
> This is still marked as "needs review" in
> https://commitfest.postgresql.org
Hi,
On 2014-01-14 18:10:40 +0900, Kyotaro HORIGUCHI wrote:
> This is cont'd from CF3.
>
> http://www.postgresql.org/message-id/20131122.165927.27412386.horiguchi.kyot...@lab.ntt.co.jp
>
> The issue in brief is that UNION is never flattened differently
> to UNION ALL so UNION cannot make use of i
Sorry, I missed to attach file.
> This is cont'd from CF3.
>
> http://www.postgresql.org/message-id/20131122.165927.27412386.horiguchi.kyot...@lab.ntt.co.jp
>
> The issue in brief is that UNION is never flattened differently
> to UNION ALL so UNION cannot make use of index scan even if
> usable.
This is cont'd from CF3.
http://www.postgresql.org/message-id/20131122.165927.27412386.horiguchi.kyot...@lab.ntt.co.jp
The issue in brief is that UNION is never flattened differently
to UNION ALL so UNION cannot make use of index scan even if
usable.
This patch flattens UNION likewise currently
Hello, As I was reconsidering after your advise, I came up with
an idea of hacking on query tree tranaformation phase in
subquery_planner, not on that of plan generation phase as
before. (And the older patch is totally scrapped:-)
Currently flatten_simple_union_all() flattens 'simple' UNION
'ALL'
Hello, I've totally refactored the series of pathes and cut out
the appropriate portion as 'UNION stuff'.
This patch rquires another 'pathkeys expansion using fully-orderd
index' patch to work.
http://www.postgresql.org/message-id/20131119.203516.251520490.horiguchi.kyot...@lab.ntt.co.jp
1. plan
Thank you for looking in detail for this patch, and giving
thoughtful advices.
> I'm aware that you said you were going to refactor this, but I took a
> quick look through it anyway. I don't think mere refactoring is going
> to make me happy with it :-(.
Ouch.. Anyway I've refactored this patch
Kyotaro HORIGUCHI writes:
> [ union_uses_idx_v2_20131113.patch ]
I'm aware that you said you were going to refactor this, but I took a
quick look through it anyway. I don't think mere refactoring is going
to make me happy with it :-(.
The basic problem here, as well as with some of the hackery
Hello, As I mentioned on another thread, I'll reorganize patches
including this and repost them.
Please wait for a while.
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
On Wed, 2013-11-13 at 17:25 +0900, Kyotaro HORIGUCHI wrote:
> Added explicit cast there and rebased to current master.
> Checked no new warning by this patch.
> make check succeeded at both $(src) and $(src)/src/test.
This patch also has whitespace errors detected by git diff --check.
--
Sent
Thank you for pointing out. I missed the warning.
> There is a new compiler warning:
>
> setrefs.c: In function ‘set_plan_refs’:
> setrefs.c:782:7: warning: initialization from incompatible pointer type
> [enabled by default]
Added explicit cast there and rebased to current master.
Checked no ne
On 10/31/13, 6:42 AM, Kyotaro HORIGUCHI wrote:
> Hello, This patch might be too complicated (and seems somewhat ad
> hoc) for the gain, but more index usage for this kind of
> operation should be worth doing.
There is a new compiler warning:
setrefs.c: In function ‘set_plan_refs’:
setrefs.c:782:7
15 matches
Mail list logo
