|From:||Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru>|
|To:||David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Generating partitioning tuple conversion maps faster|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 06/25/2018 08:00 AM, David Rowley wrote:
> I'd have expected Test 6 to do about 480-500tps. Adding debug to check
> why it's not revealed that the search is doing what's expected. I'm
> unsure why it has not improved more.
I think I found one possible reason for this slowness. Your patch
behaves as expected when there is a dropped output column, but does one
extra comparison when there is a dropped input column. This backwards
conversion is called from ExecInitRoutingInfo. To fix this, I'd just
keep a persistent inner loop counter (see the attached patch).
Still, fixing this doesn't improve the performance. According to perf
report, updatepd.sql spends 25% of time in strcmp, and updatep.sql about
0.5%, but they are comparing the same column names, even with the same
alignment and relative offsets. I'm completely puzzled by this.
As a side thought, we wouldn't have to go through this if we had a hash
table that is easy to use, or perhaps string interning in catcache.
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
|Next Message||Robert Haas||2018-06-28 14:26:13||Re: Forbid referencing columns by names in ALTER INDEX ... SET STATISTICS|
|Previous Message||Bruce Momjian||2018-06-28 13:26:13||Tips on committing|