Tomas Vondra-4 wrote > Please share explain plans for both the slow and the fast query. That > makes it easier to spot the difference, and possibly identify the cause. > > Also, what PostgreSQL version is this, and what are "basic" config > parameters (shared buffers, work mem)? I am running 9.4.4, here are the basic config parameters: work_mem = 32 MB shared_buffers = 8196 MB temp_buffers = 8 MB effective_cache_size = 4 GB I have run ANALYZE on all tables prior to running the queries. The query plan for the fast version (without the WHERE clause) follows: <http://postgresql.nabble.com/file/n5864075/qp2.png> What I don't understand is the difference between the inner NESTED LOOP between the slow and the fast query plan. In the fast one, both index scans have 1000 as the actual row count. I would expect that, given the LIMIT clause. The slow query plan, however, shows ~ 75 000 000 as the actual row count. Is the extra WHERE condition the only and *plausible* explanation for this difference? David G. Johnston wrote > I would probably try something like: > > WITH docs AS ( SELECT ... WHERE date > ...) > SELECT ... FROM (translations join translation_unit) t > WHERE EXISTS (SELECT 1 FROM docs WHERE t.doc_id = docs.doc_id) > ORDER BY t.id LIMIT 1000 David, I tried this and it is probably as slow as the original query. It did not finish in 5 minutes anyway. -- View this message in context: http://postgresql.nabble.com/Query-1-000-000-slowdown-after-adding-datetime-comparison-tp5864045p5864075.html Sent from the PostgreSQL - performance mailing list archive at Nabble.com. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
