Re: Changing SQL Inlining Behaviour (or...?)
От | Paul Ramsey |
---|---|
Тема | Re: Changing SQL Inlining Behaviour (or...?) |
Дата | |
Msg-id | 3D6D6871-5F63-4C0D-AA18-91D5C4E43F3A@cleverelephant.ca обсуждение исходный текст |
Ответ на | Re: Changing SQL Inlining Behaviour (or...?) (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Changing SQL Inlining Behaviour (or...?)
|
Список | pgsql-hackers |
> On Jan 21, 2019, at 3:27 PM, Andres Freund <andres@anarazel.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
В списке pgsql-hackers по дате отправления: