Re: Performance regression with PostgreSQL 11 and partitioning

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, Amit Langote <amitlangote09@gmail.com>, Thomas Reiss <thomas.reiss@dalibo.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-06-08T19:08:12Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> That being said, I don't mind a bit if you want to look for further
> speedups here, but if you do, keep in mind that a lot of queries won't
> even use partition-wise join, so all of the arrays will be of length
> 1.  Even when partition-wise join is used, it is quite likely not to
> be used for every table in the query, in which case it will still be
> of length 1 in some cases.  So pessimizing nappinfos = 1 even slightly
> is probably a regression overall.

TBH, I am way more concerned about the pessimization introduced for
every pre-existing usage of these functions by putting search loops
into them at all.  I'd like very much to revert that.  If we can
replace those with something along the line of root->index_array[varno]
we'll be better off across the board.

			regards, tom lane


Commits

  1. Fix typo in comment

  2. Allow direct lookups of AppendRelInfo by child relid

  3. Teach adjust_appendrel_attrs(_multilevel) to do multiple translations.