On Oct 7, 2006, at 8:50 PM, Denis Lussier wrote:
Wouldn't PG supporting simple optmizer hints get around this kinda
problem? Seems to me that at least one customer posting per week
would be solved via the use of simple hints.
If the community is interested... EnterpriseDB has added support
Denis,
Wouldn't PG supporting simple optmizer hints get around this kinda
problem? Seems to me that at least one customer posting per week
would be solved via the use of simple hints.
... and add 100 other problems. Hints are used because the DBA thinks that
they are smarter than the
... and add 100 other problems. Hints are used because the DBA thinks that
they are smarter than the optimizer; 99% of the time, they are wrong.
Just try manually optimizing a complex query, you'll see -- with three
join types, several scan types, aggregates, bitmaps, internal and external
Josh Berkus josh@agliodbs.com writes:
Now, if you were offering us a patch to auto-populate the statistics as a
table is loaded, I'd be all for that.
Curiously enough, I was just thinking about that after reading Craig's
post. autovacuum will do this, sort of, if it's turned on --- but its
Jonah H. Harris wrote:
On Oct 08, 2006 07:05 PM, Josh Berkus josh@agliodbs.com wrote:
Hints are used because the DBA thinks that they are smarter than
the optimizer; 99% of the time, they are wrong.
That's a figure which I'm 100% sure cannot be backed up by fact.
Just try manually
Craig A. James wrote:
My example, discussed previously in this forum, is a classic. I have a
VERY expensive function (it's in the class of NP-complete problems, so
there is no faster way to do it). There is no circumstance when my
function should be used as a filter, and no circumstance
Bruce Momjian wrote:
I can do 100! on my computer, but can't do it in my head.
A poor example. 100! is a simple repetative calculation, something computers
are very good at. Optimizing an SQL query is very difficult, and a completely
different class of problem.
The fact is the PG team has
Mark Kirkwood wrote:
The result? I can't use my function in any WHERE clause that involves
any other conditions or joins. Only by itself. PG will occasionally
decide to use my function as a filter instead of doing the join or the
other WHERE conditions first, and I'm dead.
this is an
On Thu, Oct 05, 2006 at 09:30:45AM -0400, Merlin Moncure wrote:
I personally only use explicit joins when doing outer joins and even
them push them out as far as possible.
I used to be like that too, until I actually started using join syntax.
I now find it's *way* easier to identify what the
On Fri, Oct 06, 2006 at 02:53:35PM -0400, Merlin Moncure wrote:
On 10/6/06, Scott Marlowe [EMAIL PROTECTED] wrote:
On Fri, 2006-10-06 at 11:44, Carlo Stonebanks wrote:
This didn't work right away, but DID work after running a VACUUM FULL. In
other words, i was still stuck with a sequential
[EMAIL PROTECTED] (Tom Lane) writes:
Another thing we've been beat up about in the past is that loading a
pg_dump script doesn't ANALYZE the data afterward...
Do I misrecall, or were there not plans (circa 7.4...) to for pg_dump
to have an option to do an ANALYZE at the end?
I seem to remember
Craig A. James wrote:
Perhaps you scanned past what I wrote a couple paragraphs farther down.
I'm going to repeat it because it's the KEY POINT I'm trying to make:
Craig James wrote:
Now you might argue that function-cost needs to be added to the
optimizer's arsenal of tricks. And I'd
Mark Kirkwood [EMAIL PROTECTED] writes:
True enough - but (aside from the fact that hints might take just as
long to get into the development tree as cost-for-functions might take
to write and put in...) there is a nasty side effect to adding hints -
most of the raw material for optimizer
13 matches
Mail list logo
