Tom,
> [ Sorry for slow response, I've been out of town ]
Taking a much-deserved vacation, hey? Any new job plans?
> Postgres absolutely does not care: the optimizer will always consider
> both A-join-B and B-join-A orders for every join it has to do. As
> Stephan and Josh noted, you can cons
[ Sorry for slow response, I've been out of town ]
"Robert J. Sanford, Jr." <[EMAIL PROTECTED]> writes:
> [ some questions already ably answered by Josh and Stephan ]
I just wanted to throw in one more tidbit:
> for example, one thing that one of my friends said is:
>select X
>from big_
On Sun, 9 Sep 2001, Josh Berkus wrote:
> Ah. Well, you answer optimization questions so often that I'd assumed
> that you had a hand in it. Is the optimizer all Tom and Bruce's work?
Mostly Tom I believe.
> > At least on 7.1 and below, if you have a dummy value that is very
> > common
> > bu
Stephan,
Ah. Well, you answer optimization questions so often that I'd assumed
that you had a hand in it. Is the optimizer all Tom and Bruce's work?
> At least on 7.1 and below, if you have a dummy value that is very
> common
> but doesn't really pass any information (like 'N/A' for example),
On Sun, 9 Sep 2001, Josh Berkus wrote:
> > i have several friends that are DBA's by profession and work on
> > oracle
> > and/or ms sql server. they have all told me that while there are some
> > general rules to follow that each database is different.
>
> Yup. They told ya right.
>
> > for e
Robert,
I'd advise you to buy a book, but frankly I don't know a good one on DB
performance optimization. The DB optimizers I've met tend to guard
their secrets closely.
Suggestions, anyone?
> i have several friends that are DBA's by profession and work on
> oracle
> and/or ms sql server. they
