this entire thing is not about cartesian products at all.
it is about kicking out expensive queries before they even start to
eat up tons of CPU.
imagine a user asking for give me all phone call in the US within the
past 10 years. you could kill the guy instantly because you know that
Josh Berkus wrote:
Greg,
Well that's going to depend on the application But I suppose there's
nothing wrong with having options which aren't always a good idea to use.
The
real question I guess is whether there's ever a situation where it would be
a
good idea to use this. I'm
Bruce Momjian wrote:
Josh Berkus wrote:
...simple web applications, where
queries are never supposed to take more than 50ms. If a query turns up
with an estimated cost of 100, then you know something's wrong;
...
How about a simpler approach that throws an error or warning for
Ron Mayer wrote:
Bruce Momjian wrote:
Josh Berkus wrote:
...simple web applications, where
queries are never supposed to take more than 50ms. If a query turns up
with an estimated cost of 100, then you know something's wrong;
...
How about a simpler approach that throws
Bruce Momjian [EMAIL PROTECTED] writes:
Ron Mayer wrote:
Seems less fool-proof to me.
My point is that people should _know_ they are using a cartesian
product, and a warning would do that for users who have no need for a
cartesian product and want to be warned about a possible error.
There
My point is that people should _know_ they are using a cartesian
product, and a warning would do that for users who have no need for a
cartesian product and want to be warned about a possible error.
I think Cartesian products are a red herring. Cartesian products are
primarily bad if they
Bruce,
How about a simpler approach that throws an error or warning for
cartesian products? That seems fool-proof.
Well, throwing a warning is pretty useless for an unattended application.
Also, it's perfectly possible to write queries which will never complete
without a cartesian join.
On Aug 3, 2008, at 9:57 PM, Robert Treat wrote:
I think a variation on this could be very useful in development
and test
environments. Suppose it raised a warning or notice if the cost
was over
the limit. Then one could set a limit of a few million on the
development
and test servers and
On Aug 4, 2008, at 3:49 PM, Simon Riggs wrote:
On Mon, 2008-08-04 at 14:35 -0400, Robert Treat wrote:
On Monday 04 August 2008 03:50:40 daveg wrote:
And you'll note, I specifically said that a crude tool is better than
nothing. But your completely ignoring that a crude tool can often
end-up
On Aug 4, 2008, at 1:04 PM, daveg wrote:
Ok, that is a different use case where an error seems very useful.
What
about slightly extending the proposal to have the severity of
exceeding
the limit configurable too. Something like:
costestimate_limit = 10 # default 0 to
Simon Riggs wrote:
On Sun, 2008-08-03 at 22:09 +0200, Hans-Jürgen Schönig wrote:
Another alternative would be to have a plugin that can examine the
plan
immediately after planner executes, so you can implement this
yourself,
plus some other possibilities.
this would be really fancy.
On Sun, 2008-08-03 at 22:57 -0400, Robert Treat wrote:
I still think it is worth revisiting what problems people are trying
to solve, and see if there are better tools they can be given to solve
them. Barring that, I suppose a crude solution is better than
nothing, though I fear people
On Sun, Aug 03, 2008 at 10:57:55PM -0400, Robert Treat wrote:
ISTR that what ended up killing the enthusiasm for this was that most people
realized that this GUC was just a poor tool to take a stab at solving other
problems (ie. rate limiting cpu for queries).
I'm not concerned with that,
Josh Berkus [EMAIL PROTECTED] writes:
Tom,
Wasn't this exact proposal discussed and rejected awhile back?
We rejected Greenplum's much more invasive resource manager, because it
created a large performance penalty on small queries whether or not it was
turned on. However, I don't
On Monday 04 August 2008 03:50:40 daveg wrote:
On Sun, Aug 03, 2008 at 10:57:55PM -0400, Robert Treat wrote:
ISTR that what ended up killing the enthusiasm for this was that most
people realized that this GUC was just a poor tool to take a stab at
solving other problems (ie. rate limiting
Greg,
Well that's going to depend on the application But I suppose there's
nothing wrong with having options which aren't always a good idea to use. The
real question I guess is whether there's ever a situation where it would be a
good idea to use this. I'm not 100% sure.
I can think of
On Mon, 4 Aug 2008, daveg wrote:
On Sun, Aug 03, 2008 at 10:57:55PM -0400, Robert Treat wrote:
Not such a great argument. Cost models on development servers can and often
are quite different from those on production, so you might be putting an
artifical limit on top of your developers.
We
On Mon, Aug 04, 2008 at 03:09:34PM -0400, Greg Smith wrote:
On Mon, 4 Aug 2008, daveg wrote:
We load the production dumps into our dev environment, which are the same
hardware spec, so the costs should be identical.
Not identical, just close. ANALYZE samples data from your table randomly.
On Mon, Aug 04, 2008 at 02:35:07PM -0400, Robert Treat wrote:
On Monday 04 August 2008 03:50:40 daveg wrote:
That's great for you, I am talking in the scope of a general solution. (Note
I'd also bet that even given the same hardware, different production loads
can produce different
On Mon, 2008-08-04 at 14:35 -0400, Robert Treat wrote:
On Monday 04 August 2008 03:50:40 daveg wrote:
On Sun, Aug 03, 2008 at 10:57:55PM -0400, Robert Treat wrote:
...
I still think it is worth revisiting what problems people are trying to
solve, and see if there are better tools they can
Josh Berkus [EMAIL PROTECTED] writes:
In such a production application, it is better to have false positives and
reject otherwise-OK queries becuase their costing is wrong, than to let a
single cartesian join bog down an application serving 5000 simultaneous users.
Further, with a SQL error,
On Mon, Aug 04, 2008 at 11:59:03AM -0700, Josh Berkus wrote:
Greg,
Well that's going to depend on the application But I suppose there's
nothing wrong with having options which aren't always a good idea to use.
The
real question I guess is whether there's ever a situation where it would
Hannu Krosing [EMAIL PROTECTED] wrote:
I was once told about a company, who claimed to have produced a
positively fool-proof lawn-mower, only to find out, that a
university
professor had tried to use it to trim a hedge and cut off his toes.
Odd. Seriously, about 45 years ago I lived next
On Mon, 2008-08-04 at 14:35 -0400, Robert Treat wrote:
On Monday 04 August 2008 03:50:40 daveg wrote:
And you'll note, I specifically said that a crude tool is better than
nothing. But your completely ignoring that a crude tool can often
end-up as a foot-gun once relased into the wild.
The
Greg,
For such an application this would be a major foot-gun which would give
a false sense of security simultaneously causing random outages and not
providing even the protection you're counting on.
Hmmm. That sounds like a call for some testing. While our cost estimation
has some issues,
On Monday 04 August 2008 16:49:43 Simon Riggs wrote:
On Mon, 2008-08-04 at 14:35 -0400, Robert Treat wrote:
On Monday 04 August 2008 03:50:40 daveg wrote:
And you'll note, I specifically said that a crude tool is better than
nothing. But your completely ignoring that a crude tool can
On Monday 04 August 2008 15:56:25 daveg wrote:
On Mon, Aug 04, 2008 at 02:35:07PM -0400, Robert Treat wrote:
On Monday 04 August 2008 03:50:40 daveg wrote:
That's great for you, I am talking in the scope of a general solution.
(Note I'd also bet that even given the same hardware,
On Mon, Aug 04, 2008 at 05:19:50PM -0400, Robert Treat wrote:
See, this is what we ended up talking about before. Someone will say I'd
like
to prevent my devs from accidentally doing queries with cartesian products
and they will use this to do it... but that will only work in some cases, so
On Sat, Aug 02, 2008 at 09:30:08PM +0200, Hans-Jürgen Schönig wrote:
On Aug 2, 2008, at 8:38 PM, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Hans-Jürgen Schönig wrote:
i introduced a GUC called statement_cost_limit which can be used to
error out if a statement is expected to be
On Sun, 2008-08-03 at 00:44 -0700, daveg wrote:
On Sat, Aug 02, 2008 at 09:30:08PM +0200, Hans-Jürgen Schönig wrote:
On Aug 2, 2008, at 8:38 PM, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Hans-Jürgen Schönig wrote:
i introduced a GUC called statement_cost_limit which can
hello ...
I still support it. Regrettably, many SQL developers introduce product
joins and other unintentional errors. Why let problem queries through?
i think the killer is that we don't have to wait until the query dies
with a statement_timeout.
it is ways more elegant to kill things
On Sun, 2008-08-03 at 22:09 +0200, Hans-Jürgen Schönig wrote:
Another alternative would be to have a plugin that can examine the
plan
immediately after planner executes, so you can implement this
yourself,
plus some other possibilities.
this would be really fancy.
how could a
Tom,
Wasn't this exact proposal discussed and rejected awhile back?
We rejected Greenplum's much more invasive resource manager, because it
created a large performance penalty on small queries whether or not it was
turned on. However, I don't remember any rejection of an idea as simple
as a
On Sunday 03 August 2008 15:12:22 Simon Riggs wrote:
On Sun, 2008-08-03 at 00:44 -0700, daveg wrote:
On Sat, Aug 02, 2008 at 09:30:08PM +0200, Hans-Jürgen Schönig wrote:
On Aug 2, 2008, at 8:38 PM, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Hans-Jürgen Schönig wrote:
i
Josh Berkus wrote:
Tom,
Wasn't this exact proposal discussed and rejected awhile back?
We rejected Greenplum's much more invasive resource manager, because it
created a large performance penalty on small queries whether or not it was
turned on. However, I don't remember any
hello ...
i picked up csaba nagy's idea and implemented a very simple yet very
useful extension.
i introduced a GUC called statement_cost_limit which can be used to
error out if a statement is expected to be too expensive.
the advantage over statement_timeout is that we are actually able to
Hans-Jürgen Schönig wrote:
hello ...
i picked up csaba nagy's idea and implemented a very simple yet very
useful extension.
i introduced a GUC called statement_cost_limit which can be used to
error out if a statement is expected to be too expensive.
the advantage over statement_timeout is
Andrew Dunstan [EMAIL PROTECTED] writes:
Hans-Jürgen Schönig wrote:
i introduced a GUC called statement_cost_limit which can be used to
error out if a statement is expected to be too expensive.
You clearly have far more faith in the cost estimates than I do.
Wasn't this exact proposal
On Aug 2, 2008, at 8:38 PM, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Hans-Jürgen Schönig wrote:
i introduced a GUC called statement_cost_limit which can be used to
error out if a statement is expected to be too expensive.
You clearly have far more faith in the cost
39 matches
Mail list logo
