> Probably the most severe objection to doing things this way is that the > selected plan could change unexpectedly as a result of the physical > table size changing. Right now the DBA can keep tight rein on actions > that might affect plan selection (ie, VACUUM and ANALYZE), but that > would go by the board with this. OTOH, we seem to be moving towards > autovacuum, which also takes away any guarantees in this department.
But aren't we requiring that we can disable autovacuum on some tables? I've actually used, more than once, the finger-on-the-scale method of thumping values in pg_class when I had a pretty good idea of how the table was changing, particularly when it would change in such a way as to confuse the planner. There are still enough cases where the planner doesn't quite get things right that I'd really prefer the ability to give it clues, at least indirectly. I can't imagine that there's going to be a lot of enthusiasm for hints, so anything that isn't a sure-fire planner helper is a potential loss, at least to me. A -- Andrew Sullivan | [EMAIL PROTECTED] I remember when computers were frustrating because they *did* exactly what you told them to. That actually seems sort of quaint now. --J.D. Baldwin ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly