Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range
Date
Msg-id 2D16D538-74F7-4D11-87FD-32D8D955549A@yesql.se
Whole thread Raw
In response to Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-hackers
> On 18 Aug 2017, at 08:50, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>
> The following review has been posted through the commitfest application:
> make installcheck-world:  tested, failed
> Implements feature:       tested, failed
> Spec compliant:           tested, failed
> Documentation:            tested, failed
>
> Hi! I've looked into the patch.
>
> There is not so much of the code. The code itself is pretty clear and well documented. I've found just one small typo
"transactionn"in HeapTupleSatisfiesNonVacuumable() comments. 
>
> Chosen Snapshot type is not a solution to the author's problem at hand. Though implemented SnapshotNonVacuumable is
closerto rational choice  than currently used SnapshotDirty for range sketching. As far as I can see this is what is
get_actual_variable_range()is used for, despite word "actual" in it's name.  
> The only place where get_actual_variable_range() is used for actual range is preprocessed-out in
get_variable_range():
>     /*
>      * XXX It's very tempting to try to use the actual column min and max, if
>      * we can get them relatively-cheaply with an index probe.  However, since
>      * this function is called many times during join planning, that could
>      * have unpleasant effects on planning speed.  Need more investigation
>      * before enabling this.
>      */
> #ifdef NOT_USED
>     if (get_actual_variable_range(root, vardata, sortop, min, max))
>         return true;
> #endif
>
> I think it would be good if we could have something like "give me actual values, but only if it is on first index
page",like conditional locks. But I think this patch is a step to right direction. 

Thanks for your review!  Based on your review and conclusions, I’ve bumped the
status to “Ready for Committer”. If you believe another status would be more
appropriate, please go in an update.

cheers ./daniel




pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: [HACKERS] WAL logging problem in 9.4.3?
Next
From: Jeevan Chalke
Date:
Subject: Re: [HACKERS] Replacing lfirst() with lfirst_node() appropriately in planner.c