| From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
|---|---|
| To: | Melvin Davidson <melvin6925(at)gmail(dot)com>, Yavuz Selim Sertoğlu <yavuzselim(dot)sertoglu(at)bisoft(dot)com(dot)tr> |
| Cc: | "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Query running for 12 hours |
| Date: | 2018-05-30 14:09:38 |
| Message-ID: | 2b9d5e83-0acb-09b9-8bb4-c44a82579996@aklaver.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 05/30/2018 07:00 AM, Melvin Davidson wrote:
>
>
>
> T*wo things:
> *
> *From your explain, it looks like you need an index on this_.tarih,
> since it is doing a sequential scan when it should be using an index.*
> *
> *
> *Also, your main problem is that when you have two exact same queries
> executing at the same time, they will cause contention in*
> *the disk, and neither one will make much progress.
I am having a hard time seeing how two SELECT queries that on average
take ~6 secs each can stay in contention for 12+ hours, especially with:
waiting | f
> *
>
> --
> *Melvin Davidson**
> Maj. Database & Exploration Specialist**
> Universe Exploration Command – UXC***
> Employment by invitation only!
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yavuz Selim Sertoğlu | 2018-05-30 14:19:12 | Re: Query running for 12 hours |
| Previous Message | Adrian Klaver | 2018-05-30 14:02:04 | Re: Query running for 12 hours |