Re: Hints proposal - Mailing list pgsql-performance

From Csaba Nagy
Subject Re: Hints proposal
Date
Msg-id 1161005266.28751.145.camel@coppola.muc.ecircle.de
Whole thread Raw
In response to Re: Hints proposal  (Mark Kirkwood <markir@paradise.net.nz>)
Responses Re: Hints proposal
Re: Hints proposal
List pgsql-performance
> 2d) Hints will damage the ongoing development of the optimizer by
> reducing or eliminating test cases for its improvement.

You have no evidence for this. The mindset of the postgres community you
cite further below usually mandates that you say things if you have
evidence for them... and this one could be even backwards, by putting
such a tool in normal mortals hands that they can experiment with
execution plans to see which one works better, thus giving more data to
the developers than it is possible now. This is of course a speculation
too, but not at all weaker than yours.

> 2e) Hints will divert developer resource away from ongoing development
> of the optimizer.

This is undebatable, although the long term cost/benefit is not clear.
And I would guess simple hinting would not need a genius to implement it
as planner optimizations mostly do... so it could possibly be done by
somebody else than the core planner hackers (is there any more of them
than Tom ?), and such not detract them too much from the planner
optimization tasks.

> 2f) Hints may demoralize the developer community - many of whom will
> have been attracted to Postgres precisely because this was a realm where
> crude solutions were discouraged.

I still don't get it why are you so against hints. Hints are a crude
solution only if you design them to be like that... otherwise they are
just yet another tool to get the work done, preferably now.

> I understand that these points may seem a bit 'feel-good' and intangible
> - especially for the DBA's moving to Pg from Oracle, but I think they
> illustrate the mindset of the Postgres developer community, and the
> developer community is, after all - the primary reason why Pg is such a
> good product.

I fail to see why would be a "hinted" postgres an inferior product...

> Of course - if we can find a way to define 'hint like' functionality
> that is more in keeping with the 'Postgres way' (e.g. some of the
> relation level statistical additions as discussed), then some of 2d-2f)
> need not apply.

I bet most of the users who wanted hints are perfectly fine with any
variations of it, if it solves the problems at hand.

Cheers,
Csaba.



pgsql-performance by date:

Previous
From: David Boreham
Date:
Subject: Re: measuring shared memory usage on Windows
Next
From: "Merlin Moncure"
Date:
Subject: Re: Performance Optimization for Dummies 2 - the SQL