Added to TODO:
* Add GUC to issue notice about queries that use unjoined tables
---
Kevin Brown wrote:
Greg Stark wrote:
Kevin Brown [EMAIL PROTECTED] writes:
Hence, it makes sense to go ahead and run
Greg Stark wrote:
Kevin Brown [EMAIL PROTECTED] writes:
Hence, it makes sense to go ahead and run the query, but issue a
warning at the very beginning, e.g. WARNING: query JOINs tables list
of tables without otherwise referencing or making use of those
tables. This may cause excessively poor
Greg Stark wrote:
Kevin Brown [EMAIL PROTECTED] writes:
Hence, it makes sense to go ahead and run the query, but issue a
warning at the very beginning, e.g. WARNING: query JOINs tables list
of tables without otherwise referencing or making use of those
tables. This may cause
On Wed, 2005-03-09 at 11:02 +1100, Neil Conway wrote:
Oleg Bartunov wrote:
I just noticed a little optimizer problem - in second query there is
unused 'tycho t2' table alias which gets backend buried.
It's not an unused table alias, it is specifying the cartesian product
of `tycho' with
Simon Riggs wrote:
Oleg is saying that the optimizer doesn't protect against foolish SQL
requests. His query is an example of a foolishly written query.
IMHO calling this a foolishly written query is completely arbitrary. I
can imagine plenty of applications for which a cartesian join makes
Oleg, this idea doesn't seem destine for greatness, so it might be worth
adding that you can avoid the general case problem of incorrectly-
specified-but-long-running query by using statement_timeout...
On Wed, 2005-03-09 at 22:38 +1100, Neil Conway wrote:
Simon Riggs wrote:
Oleg is saying
On Wed, 9 Mar 2005, Simon Riggs wrote:
Oleg, this idea doesn't seem destine for greatness, so it might be worth
adding that you can avoid the general case problem of incorrectly-
specified-but-long-running query by using statement_timeout...
I have no problem with that ! I just wanted to take a
Neil Conway [EMAIL PROTECTED] writes:
In any case, when this problem does occur, it is obvious to the user that
something is wrong, and no harm is done.
I don't see why you say that. The whole complaint here is that it's *not*
obvious something is wrong and there *is* damage until it's
Simon, Neil, all:
IMHO calling this a foolishly written query is completely arbitrary. I
can imagine plenty of applications for which a cartesian join makes
sense. In this case the user didn't write the query they meant to write
-- but it is surely hopeless to prevent that in the general case
Neil Conway wrote:
Simon Riggs wrote:
Oleg is saying that the optimizer doesn't protect against foolish SQL
requests. His query is an example of a foolishly written query.
IMHO calling this a foolishly written query is completely arbitrary. I
can imagine plenty of applications for which a
Kevin Brown [EMAIL PROTECTED] writes:
Hence, it makes sense to go ahead and run the query, but issue a
warning at the very beginning, e.g. WARNING: query JOINs tables list
of tables without otherwise referencing or making use of those
tables. This may cause excessively poor performance of
Hi there,
I just noticed a little optimizer problem - in second query there is
unused 'tycho t2' table alias which gets backend buried. This is
artificial query, I just tried to check if optimizier could recognize
this.
tycho=# explain analyze select t.pm_ra,t.pm_dec from tycho t where t.pm_ra
Oleg Bartunov wrote:
I just noticed a little optimizer problem - in second query there is
unused 'tycho t2' table alias which gets backend buried.
It's not an unused table alias, it is specifying the cartesian product
of `tycho' with itself. I don't see how this is an optimizer problem:
it's a
13 matches
Mail list logo
