Explain's estimation differs from real count enormously

Started by Sergey Konoplevover 17 years ago5 messagesgeneral
Jump to latest
#1Sergey Konoplev
gray.ru@gmail.com

Hi,

My environment is:

PostgreSQL 8.3.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.2.3
(Ubuntu 4.2.3-2ubuntu7)
+ recent patch from Teodor Sigaev

EXPLAIN ANALYZE of the query shows strange estimated rows count:

EXPLAIN ANALYZE SELECT * FROM objonmap
WHERE 1=1
AND box(om_point, om_point) <@ box(point(-55.97398205077, -100),
point(82.166446008477, 180))
AND (om_flag OR om_ref_id IN (69000001071, 69000001513,
69000001092, 69000001091))
AND om_state = 1;

Index Scan using i_objonmap__geo on objonmap (cost=0.00..7.80 rows=54
width=556) (actual time=0.085..241.089 rows=55107 loops=1)
Index Cond: (box(om_point, om_point) <@
'(82.166446008477,180),(-55.97398205077,-100)'::box)
Filter: (om_flag OR (om_ref_id = ANY
('{69000001071,69000001513,69000001092,69000001091}'::bigint[])))
Total runtime: 259.286 ms

I had thought firstly that It is because of the index until I tried
turning indexscan and bitmapscan off:

SET enable_indexscan TO OFF;
SET enable_bitmapscan TO OFF;

Seq Scan on objonmap (cost=0.00..30725.14 rows=54 width=556) (actual
time=0.042..133.192 rows=55107 loops=1)
Filter: ((om_state = 1) AND (om_flag OR (om_ref_id = ANY
('{69000001071,69000001513,69000001092,69000001091}'::bigint[]))) AND
(box(om_point, om_point) <@
'(82.166446008477,180),(-55.97398205077,-100)'::box))
Total runtime: 151.589 ms

Could somebody explain me why it happens and how to make it work right?

--
Regards,
Sergey Konoplev
--
PostgreSQL articles in english & russian
http://gray-hemp.blogspot.com/search/label/postgresql/

#2Grzegorz Jaśkiewicz
gryzman@gmail.com
In reply to: Sergey Konoplev (#1)
Re: Explain's estimation differs from real count enormously

run vacuum analyze <table>; before running that query, is it still off after
that ?

#3Sergey Konoplev
gray.ru@gmail.com
In reply to: Grzegorz Jaśkiewicz (#2)
Re: Explain's estimation differs from real count enormously

run vacuum analyze <table>; before running that query, is it still off after
that ?

I forgot to mention that ANALYZE, VACUUM ANALYZE even w/ FULL and
REINDEX doesn't help.

--
Regards,
Sergey Konoplev
--
PostgreSQL articles in english & russian
http://gray-hemp.blogspot.com/search/label/postgresql/

#4Sergey Konoplev
gray.ru@gmail.com
In reply to: Sergey Konoplev (#1)
Re: Explain's estimation differs from real count enormously

EXPLAIN ANALYZE of the query shows strange estimated rows count:

EXPLAIN ANALYZE SELECT * FROM objonmap
WHERE 1=1
AND box(om_point, om_point) <@ box(point(-55.97398205077, -100),
point(82.166446008477, 180))
AND (om_flag OR om_ref_id IN (69000001071, 69000001513,
69000001092, 69000001091))
AND om_state = 1;

One more thing - removing condition "AND box(om_point, om_point) <@
box(point(-55.97398205077, -100), point(82.166446008477, 180))" leads
to good (right) estimation.

BTW, pg 8.3.3 behave the same.

--
Regards,
Sergey Konoplev
--
PostgreSQL articles in english & russian
http://gray-hemp.blogspot.com/search/label/postgresql/

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Sergey Konoplev (#1)
Re: Explain's estimation differs from real count enormously

"Sergey Konoplev" <gray.ru@gmail.com> writes:

Could somebody explain me why it happens and how to make it work right?

Implement a selectivity estimator for <@ that isn't just a stub :-(

regards, tom lane