| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Craig James <cjames(at)emolecules(dot)com> |
| Cc: | Joe Conway <mail(at)joeconway(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Kevin Grittner <kgrittn(at)mail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, David Greco <David_Greco(at)harte-hanks(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Hints (was Poor performance using CTE) |
| Date: | 2012-11-21 17:39:46 |
| Message-ID: | 6609.1353519586@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Craig James <cjames(at)emolecules(dot)com> writes:
> On Wed, Nov 21, 2012 at 9:25 AM, Joe Conway <mail(at)joeconway(dot)com> wrote:
>> I like this idea, but also think that if we have a syntax to allow
>> hints, it would be nice to have a simple way to ignore all hints (yes, I
>> suppose I'm suggesting yet another GUC). That way after sprinkling your
>> SQL with hints, you could easily periodically (e.g. after a Postgres
>> upgrade) test what would happen if the hints were removed.
> Or a three-way choice: Allow, ignore, or generate an error. That would
> allow developers to identify where hints are being used.
Throwing errors would likely prevent you from reaching all parts of your
application, thus preventing complete testing. Much more sensible to
just log such queries.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andreas Kretschmer | 2012-11-21 17:48:08 | Re: Hints (was Poor performance using CTE) |
| Previous Message | Joe Conway | 2012-11-21 17:30:41 | Re: Hints (was Poor performance using CTE) |