| From: | "Imai, Yoshikazu" <imai(dot)yoshikazu(at)jp(dot)fujitsu(dot)com> |
|---|---|
| To: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, 'David Rowley' <david(dot)rowley(at)2ndquadrant(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | RE: speeding up planning with partitions |
| Date: | 2019-01-22 07:00:54 |
| Message-ID: | 0F97FA9ABBDBE54F91744A9B37151A51259E1A@g01jpexmbkw24 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tsunakawa-san
Thanks for giving the information.
I didn't use it yet, but I just used perf to clarify the difference of before and after the creation of the generic plan, and I noticed that usage of hash_seq_search() is increased about 3% in EXECUTE queries after the creation of the generic plan.
What I understand so far is about 10,000 while loops at total (4098+4098+some extra) is needed in hash_seq_search() in EXECUTE query after the creation of the generic plan.
10,000 while loops takes about 10 microsec (of course, we can't estimate correct time), and the difference of the latency between 5th and 7th EXECUTE is about 8 microsec, I currently think this causes the difference.
I don't know this problem relates to Amit-san's patch, but I'll continue to investigate it.
Yoshikazu Imai
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2019-01-22 08:08:52 | index_build does not need its isprimary argument |
| Previous Message | Tsunakawa, Takayuki | 2019-01-22 06:57:22 | RE: Thread-unsafe coding in ecpg |