From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jerry Sievers <gsievers19(at)comcast(dot)net> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Jeremy Finzel <finzelj(at)gmail(dot)com>, Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Slow planning time for simple query |
Date: | 2018-06-06 22:52:56 |
Message-ID: | 2183.1528325576@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Jerry Sievers <gsievers19(at)comcast(dot)net> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> 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?
I believe the slot would hold back global xmin and thereby prevent
"recently-dead" rows from becoming just plain "dead", so yeah, this
observation does seem to square with the get_actual_variable_range
theory. You'd still need to posit that something had recently deleted
a lot of rows at the end of the range of one of those columns, though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Claeys | 2018-06-07 00:14:48 | Re: Code of Conduct plan |
Previous Message | Adrian Klaver | 2018-06-06 22:51:58 | Re: Which backend using which pg_temp_N schema? |