Ok, I've tried everything, and the planner keeps choosing index scans
when it shouldnt.
Is there a way to disable index scans?
Antoine
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-
If a misestimate of this kind is bugging you enough that you're
willing
to change the query, I think you can fix it like this:
select ... from foo order by x limit n;
=>
select ... from (select ... from foo order by x) ss limit n;
The subselect will be planned without awarene
is gone too, and the query runs in a few millisecs!!
This is crazy, so simply by adding a LIMIT to a query, the planning is
changed in a very bad way. Does the planner use the LIMIT as a sort of
hint?
Thank you for your explanations,
Antoine Baudoux
--
Sent via pgsql-performance mailing li
id)
-> Index Scan using t_system_pkey on t_system system
(cost=0.00..6.27 rows=1 width=16) (never executed)
Index Cond: (system.id = service.system_id)
Total runtime: 0.362 ms
On May 6, 2008, at 5:38 PM, Guillaume Smet wrote:
Antoine,
On Tue, May 6, 20
Hello,
I have a query that runs for hours when joining 4 tables but takes
milliseconds when joining one MORE table to the query.
I have One big table, t_event (8 million rows) and 4 small tables
(t_network,t_system,t_service, t_interface, all < 1000 rows). This
query takes a few millisecond
