Re: [HACKERS] Small patch to fix an O(N^2) problem in foreign keys

2015-09-11 Thread Kevin Grittner
Jan Wieck wrote: >>> The patch uses a heuristic method of detecting when the hash table >>> should be destroyed and recreated. InvalidateConstraintCacheCallBack() >>> adds the current size of the hash table to a counter. When that sum >>> reaches 1,000,000, the hash table is

Re: [HACKERS] Small patch to fix an O(N^2) problem in foreign keys

2015-09-10 Thread Jan Wieck
On 09/08/2015 08:49 AM, Kevin Grittner wrote: Jan Wieck wrote: The problem is a cache introduced in commit 45ba4247 that improves That's a bit off; 45ba424f seems to be what you mean. Copy paste over paper. foreign key lookups during bulk updates when the FK value

Re: [HACKERS] Small patch to fix an O(N^2) problem in foreign keys

2015-09-08 Thread Kevin Grittner
Jan Wieck wrote: > The problem is a cache introduced in commit 45ba4247 that improves That's a bit off; 45ba424f seems to be what you mean. > foreign key lookups during bulk updates when the FK value does not > change. When restoring a schema dump from a database with many

[HACKERS] Small patch to fix an O(N^2) problem in foreign keys

2015-09-03 Thread Jan Wieck
Attached is a small patch and a script to reproduce the issue. The problem is a cache introduced in commit 45ba4247 that improves foreign key lookups during bulk updates when the FK value does not change. When restoring a schema dump from a database with many (say 100,000) foreign keys, this