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

"Kevin Grittner" <Kevin.Grittner@wicourts.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.

            regards, tom lane