Hello.
I have applied this patch and can confirm ~10% speedup by this patch in presence of big amount of inherited tables.
Test case was as suggested by Aleksander: create 1000 inherited tables, no constraints, insert a row in each one, and
issuesingle row queries over this table.
Xeon-based server 12C/24T, 50 connections, 30-min average:
TPS, no patch: 393 tps
TPS, with patch: 441 tps
The same setup but with single table with 1000 rows give performance about 188_000 tps, so overall speed of requests
overa inherited table in this scenario is quite pathological (probably this is expected because database just execute
1000selects to each inherited table). I've also tried to set range constraints for all inherited tables, so only one
tablewas affected by query, but planning time increased a lot and total tps was again about 500 tps.
Also attaching two flame graphs measured during tests. It’s clearly visible that PortalDrop takes x4 less time after
patch.
Stas.
> On 24 Dec 2015, at 12:24, Aleksander Alekseev <a.alekseev@postgrespro.ru> wrote:
>
> Oops, wrong patches - here are correct
ones.<resource-owner-optimization-v4-step1.patch><resource-owner-optimization-v4-step2.patch>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
---
Stas Kelvich
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
