| From: | Paul Ramsey <pramsey(at)cleverelephant(dot)ca> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Adam Brightwell <adam(dot)brightwell(at)crunchydata(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Geoghegan <peter(dot)geoghegan(at)crunchydata(dot)com>, Joe Conway <joe(at)crunchydata(dot)com> |
| Subject: | Re: Changing SQL Inlining Behaviour (or...?) |
| Date: | 2019-01-21 23:28:27 |
| Message-ID: | 3D6D6871-5F63-4C0D-AA18-91D5C4E43F3A@cleverelephant.ca |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Jan 21, 2019, at 3:27 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2019-01-21 15:21:29 -0800, Paul Ramsey wrote:
>> As a practical matter, most of the exact-test functions have a
>> preamble that checks the bbox, so in the seqscan case having the
>> operator along for the ride isn’t any advantage. In any event, if we
>> do have exact tests w/o a lossy preamble, we could add that for v12,
>> as this renovation won’t be a small one if we go this direction.
>
> How expensive are the bbox checks in comparison to the exact tests? IOW,
> how much of a problem is it to potentially do a bbox check twice?
Very very cheap. The geometry object usually has a bbox already instantiated and stored along with the actual coordinates. The exceptions are objects (points, two-vertex lines) that are basically their own boxes anyways.
P
>
> Greetings,
>
> Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2019-01-21 23:30:20 | Re: problems with foreign keys on partitioned tables |
| Previous Message | Andres Freund | 2019-01-21 23:27:24 | Re: Changing SQL Inlining Behaviour (or...?) |