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
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
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(岩浅 晃郎
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
(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,
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
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
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
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 &&
> +
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,
--
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
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
12 matches
Mail list logo
