From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Idea about estimating selectivity for single-column expressions |
Date: | 2009-08-19 14:16:45 |
Message-ID: | 407d949e0908190716i42de4b4eq169a9572529d34f2@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 19, 2009 at 3:53 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> * The expression might throw an error for some inputs, for instance
> (1 / field) < 0.5
> which would fail on zero. We could recover by wrapping the whole
> estimation process in a subtransaction, but that seems really expensive.
> I thought about arguing that the failure would happen anyway at runtime,
> but that doesn't hold water --- for example, the user might have just
> deleted all the rows with field = 0, and would have grounds to complain
> if the query failed; but there would still be an entry for zero in the
> histogram.
We could add another flag in pg_proc for functions which cannot throw
an error. Perhaps all index operator class operators be required to
use such functions too?
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2009-08-19 14:28:44 | Re: Idea about estimating selectivity for single-column expressions |
Previous Message | Stef Walter | 2009-08-19 13:02:26 | Re: pg_hba.conf: samehost and samenet |