Re: Generating partitioning tuple conversion maps faster

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.

--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company