Tom Lane <tgl@xxxxxxxxxxxxx> writes: > Pavel Stehule <pavel.stehule@xxxxxxxxx> writes: > >> 2018-06-06 18:59 GMT+02:00 Jeremy Finzel <finzelj@xxxxxxxxx>: >>> We have an odd scenario on one of our OLTP systems, which behaves the same >>> way on a streamer, of a 700-1000ms planning time for a query like this: >>> SELECT * >>> FROM table1 >>> WHERE source_id IN (SELECT id FROM table2 WHERE customer_id = $1); > >> more times I seen similar issue based on bloated indexes on table - pg in >> planning time detect min max from possible indexes > > Oh, hmm, yeah it could be ye olde get_actual_variable_range() issue. > When this happens, are there perhaps a lot of recently-dead rows at either > extreme of the range of table1.source_id or table2.id? We noticed the cluster of interest had a rogue physical rep slot holding 71k WAL segments. Dropping same slot seemed to correlate with the problem going away. Does that sound like a plausible explanation for the observed slow planning times? Thx > We made a fix last year to improve that: > https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=3ca930fc3 > but it wasn't back-patched. > > regards, tom lane > > -- Jerry Sievers Postgres DBA/Development Consulting e: postgres.consulting@xxxxxxxxxxx p: 312.241.7800
