Re: Slow planning time for simple query

On Mon, Jun 18, 2018 at 7:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
>> On Sun, Jun 17, 2018 at 9:22 PM, Andrew Gierth
>> <andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
>>> That's OK as long as we're ignoring those hints on the standby.
>
>> What if we don't ignore those hints on standby for a specific case
>> like the one in get_actual_variable_range?
>
> Yeah, that's the same idea I suggested upthread. Andrew shot down
> my first thought (correctly I think) but the second one still seems
> feasible.
>
>> Now, if the user has
>> enabled wal_log_hints on the master, it could save time from scanning
>> many dead tuples on standby.
>
> We should have the standby set the hint bits for itself, rather than
> relying on wal_log_hints.
>

Yeah, I think that is a good idea unless someone sees a hole in it,
but we have to keep in mind that the bits set by standby can be
overwritten later for instance (a) due to an FPI for a change on that
page in master and (b) when that page is evicted from shared buffers
because we don't allow to dirty the page during recovery. However, I
think the same is true for regular hint bits (hint bit on a tuple that
suggests transaction is committed). On the one hand it will be good
if we can do it as a single patch, but it is not difficult to imagine
that we can do this as two separate patches where the first patch can
just introduce an idea to not ignore kill bits on standby in a
particular case (get_actual_variable_range) and the second patch to
introduce something like StandbyGlobalXmin which will then be used in
get_actual_variable_range. Both are independently useful.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com