On Wed, Feb 21, 2018 at 7:28 PM, Tom Lane wrote:
>
> > What is the planner doing when trying to find the current live max value
> of
> > the column?
>
> It's trying to estimate whether a mergejoin will be able to stop short of
> reading all the tuples from the other side of the join. (For instanc
Lucas Fairchild-Madar writes:
> On Wed, Feb 21, 2018 at 4:14 PM, Tom Lane wrote:
>> If so, this might be some manifestation of a problem we've seen before:
>> the planner tries to find out the current live max value of the column
>> by scanning the index, and that's really slow if there are a lot
On Wed, Feb 21, 2018 at 4:14 PM, Tom Lane wrote:
> Lucas Fairchild-Madar writes:
> > I'm having an perplexing issue in PG 10.1 wherein deleting a large amount
> > of rows from a table causes query planning time to spike dramatically
> for a
> > while. This happens with or without autovacuums so
Lucas Fairchild-Madar writes:
> I'm having an perplexing issue in PG 10.1 wherein deleting a large amount
> of rows from a table causes query planning time to spike dramatically for a
> while. This happens with or without autovacuums so vacuuming isn't the
> issue.
Would the deleted rows happen t
