-----Original Message----- From: pgsql-performance-owner@xxxxxxxxxxxxxx [mailto:pgsql-performance-owner@xxxxxxxxxxxxxx] On Behalf Of Bucky Jordan Sent: Thursday, October 12, 2006 2:19 PM To: josh@xxxxxxxxxxxx; Jim C. Nasby Cc: pgsql-hackers@xxxxxxxxxxxxxx; pgsql-performance@xxxxxxxxxxxxxx Subject: Re: [HACKERS] [PERFORM] Hints proposal > > Well, one nice thing about the per-query method is you can post before > > and after EXPLAIN ANALYZE along with the hints. > > One bad thing is that application designers will tend to use the hint, fix > the immediate issue, and never report a problem at all. And query hints > would not be collectable in any organized way except the query log, which > would then require very sophisticated text parsing to get any useful > information at all. > Or they'll report it when the next version of Postgres "breaks" their app because the hints changed, or because the planner does something else which makes those hints obsolete. My main concern with hints (aside from the fact I'd rather see more intelligence in the planner/stats) is managing them appropriately. I have two general types of SQL where I'd want to use hints- big OLAP stuff (where I have a lot of big queries, so it's not just one or two where I'd need them) or large dynamically generated queries (Users building custom queries). Either way, I don't want to put them on a query itself. What about using regular expressions, plus, if you have a function (views, or any other statement that is stored), you can assign a rule to that particular function. So you get matching, plus explicit selection. This way it's easy to find all your hints, turn them off, manage them, etc. (Not to mention dynamically generated SQL is ugly enough without having to put hints in there). - Bucky ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
