Re: strange nested loop row count estimates
От | Sergey Koposov |
---|---|
Тема | Re: strange nested loop row count estimates |
Дата | |
Msg-id | 1556772565.7942.240.camel@cmu.edu обсуждение исходный текст |
Ответ на | Re: strange nested loop row count estimates (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: strange nested loop row count estimates
|
Список | pgsql-general |
On Thu, 2019-05-02 at 00:36 -0400, Tom Lane wrote: > Sergey Koposov <skoposov@cmu.edu> writes: > > > > I'm currently trying to understand the expected row counts for a query involving a nested loop join and bitmap indexscan > > on the functional index and a custom operator. And the numbers that I see don't make sense to me currently. > What sort of selectivity estimator have you got attached to that custom > operator? This is the code, but basically it is just a constant based on the search radius (which is the leftmost float argument ofthe operator) https://github.com/segasai/q3c/blob/361140d4f1f36bf16c9c53721d1c4f03cb4de930/q3c.c#L89 For the query in question it should be ~ 1e-12 The whole idea of the operator was to specifically inform PG that this query returns a small number of rows. (the underlying idea of the query is that it does positional crossmatch between datasets on the sphere with a certain smallradius). And obviously the selectivity of this is is extremely tiny).
В списке pgsql-general по дате отправления: