loat4.
I wrote a patch to add check this situation.
Please find attached.
Sincerely,
--
Taiki Kondo
NEC Solution Innovators, Ltd.
fix_infinity_to_1.patch
Description: fix_infinity_to_1.patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
ke_sort_from_pathkeys(),
> +* relids may be NULL. In this case, we must not ignore child
> +* members because inner/outer plan of pushed-down merge join
> is
> +* always child table.
> */
> - if (em->em_is_child &&
> +
case.
(470.269 ms @ normal vs 394.007 ms @ this feature)
I think this point is large benefit of this feature.
Best regards,
--
Taiki Kondo
NEC Solution Innovators, Ltd.
-Original Message-
From: Kaigai Kouhei(海外 浩平) [mailto:kai...@ak.jp.nec.com]
Sent: Thursday, October 15, 2015 10:21
tering conditions from CHECK() constraints.
This is to reduce number of rows for making hash table smaller (or
making sorting faster for MergeJoin) to fit to smaller work_mem environment.
Maybe, I must collect realistic examples of CHECK() constraints,
which are used for table partitioning, fo
k_constraint_mutator() to judge whether
join clause is hash-joinable or not.
Actually, I want to judge whether OpExpr as top expression tree of
join clause means "=" or not, but I can't find how to do it.
If you know how to do it, please let me know.
Best regards,
--
Taiki K
(Be careful to check whether the original path is not parametalized.)
OK. I'll try implementation by a method you mentioned.
Best regards,
--
Taiki Kondo
NEC Solution Innovators, Ltd.
-Original Message-
From: Kaigai Kouhei(海外 浩平) [mailto:kai...@ak.jp.nec.com]
Sent: Wednesday,
estimation because inner_path_rows means
> number of rows already filtered out, but filter_qual shall be applied to
> all the inner input rows.
OK. I'll fix it.
Best regards,
--
Taiki Kondo
NEC Solution Innovators, Ltd.
-Original Message-
From: pgsql-hackers-ow...@postgresq
ea7694f801134...@bpxm15gp.gisp.nec.co.jp
Best regards,
--
Taiki Kondo
NEC Solution Innovators, Ltd.
-Original Message-
From: Kaigai Kouhei(海外 浩平) [mailto:kai...@ak.jp.nec.com]
Sent: Tuesday, August 18, 2015 5:47 PM
To: Kondo Taiki(近藤 太樹); pgsql-hackers@postgresql.org
Cc: Iwaasa Akio(岩浅 晃郎
d other arrays
defined
in PlannerInfo to register new RelOptInfos for new Path nodes mentioned above.
Or, is it better choice to modify query parser to implement this feature more
further?
Remarks :
[1]
http://www.postgresql.org/message-id/9a28c8860f777e439aa12e8aea7694f80
ption.
This also may spoil user experiences because command line is longer and less
easier.
5) Neither this approach nor my proposal resolve the concern about "CREATE
INDEX".
We have to discuss more further for it.
regards,
--
Taiki Kondo
-Original Message-
From: Merl
org/message-id/116262cf971c844fb6e793f8809b51c6ea6...@bpxm02gp.gisp.nec.co.jp
How about your opinion?
regards,
--
Taiki Kondo
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Andres Freund
Sent: Friday, June 12, 2015
e programs expecting no output on stdout.
I will implement this feature if this proposal is accepted by hackers.
(Maybe, I will not use ncurses for implementing this feature, because ncurses
can not be used with standard printf family functions.)
Any comments are welcome.
Best Regards,
--
12 matches
Mail list logo
