Re: Performance regression with PostgreSQL 11 and partitioning - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Performance regression with PostgreSQL 11 and partitioning
Date
Msg-id 1853.1528484892@sss.pgh.pa.us
Whole thread Raw
In response to Re: Performance regression with PostgreSQL 11 and partitioning  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Performance regression with PostgreSQL 11 and partitioning
Re: Performance regression with PostgreSQL 11 and partitioning
List 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


pgsql-hackers by date:

Previous
From: Peter Da Silva
Date:
Subject: Re: pl/tcl function to detect when a request has been canceled
Next
From: Alvaro Herrera
Date:
Subject: Re: SHOW ALL does not honor pg_read_all_settings membership