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.
