On Thu, Nov 11, 2010 at 1:41 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > "Kevin Grittner" <Kevin.Grittner@xxxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
