Re: [HACKERS] [COMMITTERS] pgsql: Improve performance of find_all_inheritors()
On Tue, Mar 28, 2017 at 3:59 PM, Aleksander Alekseev wrote: > Hi, Robert. > >> I'm a little worried that this will be noticeably slower when the >> number of partitions is small, like 4 or 8 or 16. In other places, >> we've found it necessary to support both a list-based strategy and a >> hash-based strategy to avoid regressing small cases (e.g. >> join_rel_list + join_rel_hash in PlannerInfo, ResourceArray in >> resowner.c, etc). > > I've checked it [1]. Apparently in this particular case patches make code > faster on small amount of partitions as well. Huh. Well, in that case, cool. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Improve performance of find_all_inheritors()
Hi, Robert. > I'm a little worried that this will be noticeably slower when the > number of partitions is small, like 4 or 8 or 16. In other places, > we've found it necessary to support both a list-based strategy and a > hash-based strategy to avoid regressing small cases (e.g. > join_rel_list + join_rel_hash in PlannerInfo, ResourceArray in > resowner.c, etc). I've checked it [1]. Apparently in this particular case patches make code faster on small amount of partitions as well. [1] https://postgr.es/m/20170324132258.GB16830%40e733.localdomain -- Best regards, Aleksander Alekseev signature.asc Description: PGP signature
Re: [HACKERS] [COMMITTERS] pgsql: Improve performance of find_all_inheritors()
On Mon, Mar 27, 2017 at 12:08 PM, Teodor Sigaev wrote: > Improve performance of find_all_inheritors() > > Previous coding uses three nested loops which obviously were a pain for > large number of table's children. Patch replaces inner loop with > a hashmap. > > Author: Aleksander Alekseev > Reviewed-by: me > > https://commitfest.postgresql.org/13/1058/ I'm a little worried that this will be noticeably slower when the number of partitions is small, like 4 or 8 or 16. In other places, we've found it necessary to support both a list-based strategy and a hash-based strategy to avoid regressing small cases (e.g. join_rel_list + join_rel_hash in PlannerInfo, ResourceArray in resowner.c, etc). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
