Re: [PERFORM] Re: Query > 1000× slowdown after adding datetime comparison

Поиск

Список

Период

Сортировка

От	林士博
Тема	Re: [PERFORM] Re: Query > 1000× slowdown after adding datetime comparison
Дата	1 сентября 2015 г. 13:15:49
Msg-id	CACudzGjdZJePOvKQoPM8wAscRhq9AwB42gk3r=vQmk9dh9zY5g@mail.gmail.com обсуждение исходный текст
Ответ на	Re: Re: Query > 1000× slowdown after adding datetime comparison (twoflower <standa.kurik@gmail.com>)
Ответы	Re: [PERFORM] Re: Query > 1000× slowdown after adding datetime comparison (林士博 <lin@repica.co.jp>)
Список	pgsql-performance

Дерево обсуждения

It depends on the values in your table.

It seems that the documenttype of all the records with the smallest 1000 ids is all 4.

So, the query ends after doing nest-loop 1000 times.

2015-09-01 18:51 GMT+09:00 twoflower <standa.kurik@gmail.com>:

林士博 wrote
> I think you should try putting the precomputed boolean temp_eval column
> to "EXTERNAL_TRANSLATION" r table.
>
> And if possible, try creating a conditional index on id where temp_eval is
> true,
> on "EXTERNAL_TRANSLATION" r table.
>
> So that, only check this index can get the top 1000 records.

I agree that might help. But I would still like to understand what's the
reason for difference between the second and the third query. Both contain a
simple <column> = <constant> expression, yet one finishes immediately and
one runs for 41 minutes.

--
View this message in context: http://postgresql.nabble.com/Query-1-000-000-slowdown-after-adding-datetime-comparison-tp5864045p5864173.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance