From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | XINYULIU(at)umich(dot)edu, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #16624: Query Optimizer - Performance bug related to predicate simplification |
Date: | 2020-09-23 19:48:03 |
Message-ID: | 1505476.1600890483@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> Evidently nobody even tries to do this stuff.
Yeah. But it would be particularly hard to do in Postgres, because of
our resolutely extensible approach to data types and operators/functions.
We'd have to devise some general-purpose APIs whereby a specific data
type or function could decide whether a given transformation is valid
or safe. It's not even very clear where would be the right place to
lodge the knowledge.
If you were really intent on making this happen, you could imagine
for instance attaching a SupportRequestSimplify hook to "int4eq",
which could transform "x - c1 = c2" into "x = c1 + c2" after verifying
that the constant values wouldn't produce overflow. But this idea
doesn't scale very well, since you'd really be talking about looking
for a whole bunch of different possible rearrangements not just one.
And it's unclear how you could avoid reimplementing a bunch of that
logic for each different equality operator. On top of that, you would
have little visibility into whether this was worth the cycles, since
such code would be unlikely to know whether "x" is an indexable
value or whether the expression occurs in a place where it could
be used in an indexqual anyway.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2020-09-23 20:49:12 | Re: BUG #16624: Query Optimizer - Performance bug related to predicate simplification |
Previous Message | Zsolt Ero | 2020-09-23 19:26:34 | Re: BUG #16604: pg_dump with --jobs breaks SSL connections |