Re: Understanding query planner cpu usage - Mailing list pgsql-general

From Lucas Fairchild-Madar
Subject Re: Understanding query planner cpu usage
Date
Msg-id CAJmoq7N0eQtk_FLWLfYTLsRdu2Grq-E0m686RPPfbfR0PcbK1Q@mail.gmail.com
Whole thread Raw
In response to Re: Understanding query planner cpu usage  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Wed, Feb 21, 2018 at 7:28 PM, Tom Lane <tgl@sss.pgh.pa.us> 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 instance,
if you've got 1,3,5 on one side, and 1,4,5,7,8,9,19 on the other, the
second input doesn't have to be read past "7" because once we run off the
end of the first input, we know we couldn't see any matches later on the
second input.  So the planner wants to compare the ending key value on
each side to the key distribution on the other side, to see what this might
save.)  Now, that's a unidirectional question for any particular mergejoin
plan, so that for any one cost estimate it's only going to need to look at
one end of the key range.  But I think it will consider merge joins with
both sort directions, so that both ends of the key range will get
investigated in this way.  I might be wrong though; it's late and I've
not looked at that code in awhile ...

I'm thinking the least painful solution here might be to set enable_mergejoin = false for this particular query, since the rows joined are quite sparse.

pgsql-general by date:

Previous
From: Steve Atkins
Date:
Subject: Re: On error mesage (0x80090325) whilst installing Apps Stack Builder
Next
From: Alan Hodgson
Date:
Subject: Re: On error mesage (0x80090325) whilst installing Apps StackBuilder