Re: anti-join chosen even when slower than old plan

On Thu, Nov 11, 2010 at 1:41 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> Besides the "fully-scanned object size relative to relation size
>> costing adjustment" idea, the only one which seemed to be likely to
>> be useful for this sort of issue was the "costing factors by user
>> ID" idea -- the interactive queries hitting the well-cached portion
>> of the tables are run through a read-only user ID, while the weekly
>> maintenance scripts (obviously) are not.  With the settings I
>> initially had assigned to the cluster the maintenance scripts would
>> never have seen this issue; it was tuning to resolve end-user
>> complaints of slowness in the interactive queries which set up the
>> conditions for failure, and if I'd had per-user settings, I probably
>> would have (and definitely *should* have) used them.
>
> Erm ... you can in fact do "ALTER USER SET random_page_cost" today.
> As long as the settings are GUC parameters we have quite a lot of
> flexibility about how to control them.  This gets back to my earlier
> point that our current form of per-relation properties (reloptions) is
> considerably less flexible than a GUC.  I think that if we create any
> strong planner dependence on such properties, we're going to end up
> needing to be able to set them in all the same ways you can set a GUC.

In Kevin's particular case, would this mechanism not help? By that I
mean he could have two users: one user for the daily, the
tables-ought-to-be-in-hot-cache use case. The other use could make use
of the ALTER USER SET ... mechanism to drive the weekly reporting
(tables are probably not hot) use case.

--
Jon