Re: [GENERAL] Very slow queries w/ NOT IN preparation (seems like a bug, test case)

From: "Brendan Jurd" <direvus(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Richard Huxton" <dev(at)archonet(dot)com>, "Sergey Konoplev" <gray(dot)ru(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [GENERAL] Very slow queries w/ NOT IN preparation (seems like a bug, test case)
Date: 2008-11-12 18:03:41
Message-ID: 37ed240d0811121003v50f5f894v9973f18f5b986f03@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Thu, Nov 13, 2008 at 4:52 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Yeah. An example of a closely related expression that it *would* be
> able to prove self-contradictory is
> WHERE x = ALL (ARRAY[1, 2, ...])
> or perhaps slightly more realistically
> WHERE x = ANY (ARRAY[1, 2, 3]) AND x > 4

It seems like the cure is worse than the disease here. Surely a user
who has a self-contradictory clause will realise the problem pretty
quickly (i.e., when he receives zero rows) and then just fix it.

I guess my question is, what's the real benefit of going to all this
trouble trying to prove that clauses are false? What real-world
problem does it address?

Cheers,
BJ

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Erwin Moller 2008-11-12 18:08:03 missing FROM-clause entry for table
Previous Message Brent Wood 2008-11-12 17:56:43 Re: how to "group" several records with same timestamp into one line?

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-11-12 18:16:40 Re: [GENERAL] Very slow queries w/ NOT IN preparation (seems like a bug, test case)
Previous Message Teodor Sigaev 2008-11-12 17:55:20 Re: B-Tree emulation for GIN