--On måndag, september 29, 2003 11.12.55 -0400 Christopher Browne <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] (Palle Girgensohn) writes:Will that make a difference? From what I've seen, it does not make much difference, but I have seen queries speed up when rewritten explicit joins. I guess it depends on other things, but is it really so that the explicit joins are bad somehow? Do you have any pointers to documentation about it, if so?
The problem is that if you expressly specify the joins, the query optimizer can't choose its own paths. And while that may not be better at the moment, it is quite possible that when you upgrade to a newer version, those queries, if "not join-specified," could immediately get faster.
You've got a point here. Still, with some queries, since the data is pretty static and we know much about its distribution over the tables, we had to explicitally tell postgresql how to optimze the queries to get them fast enough. We cannot afford any queries to be more than fractions of seconds, really.
I would expect that the query that uses implicit joins will be clearer to read, which adds a little further merit to that direction.
Depends, I actually don't agree on this, but I guess it depends on which syntax you're used to.
That goes along with the usual way that it is preferable to optimize things, namely that you should start by solving the problem as simply as you can, and only proceed to further optimization if that actually proves necessary. Optimization efforts commonly add complexity and make code more difficult to maintain; that's not the place to start if you don't even know the effort is necessary.
Oh, but of course. For the queries I refer to, optimization actually proved necessary, believe me :-)
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings