[HACKERS] estimation for join results cardinality is sometimes more than the product of the downstream nodes'

Hello, Postgres can produce a plan with a nested loop node having rows estimate much more than the product of underlying nodes' estimates, relying only on outer relation size: alexey=# explain SELECT oid, relname FROM ( SELECT m.oid, m.relname FROM pg_class m UNION ALL

[HACKERS] patch: optimize information_schema.constraint_column_usage

attached for a performance test: create 3000 tables with 10 columns and a PK each and select * from the view. The last statement works for 22 seconds on master branch, 34 milliseconds optimized on my laptop. Best Regards, Alexey Bashtanov many-constraints.sql Description: application/sql diff

Re: [HACKERS] OOM on EXPLAIN with lots of nodes

ExplainPropertyText/ExplainPropertyList? Otherwise are you pretty sure ExplainPropertyText and ExplainPropertyList are not going perform any pallocs without immediate pfrees in current memory context even in future? Regards, Alexey Bashtanov -- Sent via pgsql-hackers mailing list (pgsql

[HACKERS] OOM on EXPLAIN with lots of nodes

it after a plan node is generated. Any reasons to treat this idea as bad? BTW in this case explain execution is also quite long (I got tens of seconds). But I have no immediate ideas how to improve it. Regards, Alexey Bashtanov -- Sent via pgsql-hackers mailing list (pgsql-hackers

[HACKERS] Autovacuum fails to keep visibility map up-to-date in mostly-insert-only-tables

, disabled by default)? Best regards, Alexey Bashtanov -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers