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 applying.
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 index
Andres Freund and...@2ndquadrant.com 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
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
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 new
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
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.
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
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
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.
Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp 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
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:
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 new
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
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:
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.
Currently, PostgreSQL ignores from the very first the availablity
of indexes for UNION. Sorting and SeqScan is choosed as follows,
* EX.1
16 matches
Mail list logo
