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 changes to you
LL. 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 &&
> + if (relids != NULL &&
> +
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
ECK() 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, for designing more cleanly.
ble 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 Kondo
NEC Solution Innovators, Ltd.
-Original Message-
F
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, September
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...@postgresql.org
[mailto:pgsql-hack
134...@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(岩浅 晃郎)
Subject:
further?
Remarks :
[1]
http://www.postgresql.org/message-id/9a28c8860f777e439aa12e8aea7694f8010f6...@bpxm15gp.gisp.nec.co.jp
Best regards,
--
Taiki Kondo
NEC Solution Innovators, Ltd.
QUERY PLAN
the concern about CREATE
INDEX.
We have to discuss more further for it.
regards,
--
Taiki Kondo
-Original Message-
From: Merlin Moncure [mailto:mmonc...@gmail.com]
Sent: Friday, June 12, 2015 10:42 PM
To: Taiki Kondo
Cc: pgsql-hackers@postgresql.org; Akio Iwaasa
Subject: Re: [HACKERS
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 10:48 PM
To: Taiki Kondo
Cc: pgsql-hackers@postgresql.org; Akio Iwaasa
Subject: Re: [HACKERS
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,
--
Taiki Kondo
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
12 matches
Mail list logo
