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

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(dot)kurik(at)gmail(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

--
─repica group──────────────────
▼ポイント×電子マネー×メールで店舗販促に必要な機能を全て提供！
【point+plus】http://www.repica.jp/pointplus/

▼フォローアップメールや外部連携に対応！
【mail solution】http://ms.repica.jp/

▼9年連続シェアNo.1 個人情報漏えい対策ソフト
【P-Pointer】http://ppointer.jp/

▼単月導入可能！AR動画再生アプリ
【marcs】http://www.arappli.com/service/marcs/

▼ITビジネスを創造しながら未来を創る
【VARCHAR】http://varchar.co.jp/
───────────────────────────