Re: Mini improvement: statement_cost_limit

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: "Ron Mayer" <rm_pg(at)cheapcomplexdevices(dot)com>, "Josh Berkus" <josh(at)agliodbs(dot)com>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>
Subject: Re: Mini improvement: statement_cost_limit
Date: 2008-08-15 22:03:40
Message-ID: 603c8f070808151503h15263573q76c7f5f5c1239d18@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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 generate bad performance, and bad performance
can be generated without Cartesian products. I've certainly written
them intentionally, from time to time. The bigger issue is - if you
start critiquing people's query-writing, where will you stop?

SELECT * FROM foo WHERE a = NULL
WARNING: a = NULL is always false. Did you mean id IS NULL?

SELECT * FROM foo LEFT JOIN bar ON foo.a = bar.a LEFT JOIN baz ON
foo.b = bar.b AND foo.c = baz.c
WARNING: Maybe you meant foo.b = baz.b instead of foo.b = bar.b?

I'm sure there are a hundred others - these just happen to be a few of
my old mistakes (the first one was generated by some buggy Perl
code... the second by poor cut-and-paste skills). In any event, I
don't think it's the job of the database to argue with you about
whether you really want the data you asked for - it's job is just to
get you that data. Of course if doing so will take longer than the
amount of time remaining before the heat death of the universe, a
warning might be appropriate.

...Robert

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-08-15 22:12:40 Misusing functions taking "internal" via coincidental signature match
Previous Message Tom Lane 2008-08-15 21:54:00 Re: Mini improvement: statement_cost_limit