Re: Query hitting empty tables taking 48 minutes

2018-06-18 Thread Robert Creager
> On Jun 18, 2018, at 4:33 PM, Robert Creager wrote: > >> I cannot explain the discrepancy between the runtimes of 85 seconds versus >> 10857 seconds. > > It would be nice if the auto_explain analyze did include the other > information like the psql analyze does.

Re: Query hitting empty tables taking 48 minutes

2018-06-18 Thread Robert Creager
> On Jun 18, 2018, at 4:04 PM, Laurenz Albe wrote: > > Robert Creager wrote: >> A different query started showing up as the problem, the auto_explain with >> analyze shows an oddity, >> the total query duration is 11k seconds, while the query itself is 3 &g

Re: Query hitting empty tables taking 48 minutes

2018-06-18 Thread Robert Creager
> On Jun 7, 2018, at 4:18 PM, Robert wrote: > >> You can capture the execution plan of the bad statement by using >> auto_explain, >> that would certainly shed more light on the problem. > A different query started showing up as the problem, the auto_explain with analyze shows an oddity, th

Re: Query hitting empty tables taking 48 minutes

2018-06-08 Thread Robert Creager
> On Jun 8, 2018, at 10:23 AM, David G. Johnston > wrote: > > ​Not sure what the right answer is but its seems your database (those tables > at least) are mis-configured for the workload being ​executed against them. > Significantly increasing the aggressiveness of the auto-vacuum process a

Re: Query hitting empty tables taking 48 minutes

2018-06-08 Thread Robert Creager
On Jun 7, 2018, at 4:58 PM, David G. Johnston mailto:david.g.johns...@gmail.com>> wrote: I would suspect that vacuuming these tables would solve your problem. Whether there is an issue beyond a lack of vacuuming, or related to auto-vacuum, I am unsure. Though at this point it may take a vac

Re: Query hitting empty tables taking 48 minutes

2018-06-07 Thread Robert Creager
> On Jun 7, 2018, at 4:58 PM, David G. Johnston > wrote: > > On Thu, Jun 7, 2018 at 3:02 PM, Robert Creager <mailto:rob...@logicalchaos.org>> wrote: > ​[...]​ > job_id | f | 1 | cc54ca5d-0dca-4b35-acd9-e0fe69c6b247 > > IIUC, the syst

Re: Query hitting empty tables taking 48 minutes

2018-06-07 Thread Robert Creager
Re-sending from a subscribed address (sigh). On Jun 7, 2018, at 4:18 PM, Robert wrote: > On Jun 7, 2018, at 2:15 PM, Laurenz Albe <mailto:laurenz.a...@cybertec.at>> wrote: > > Robert Creager wrote: >> I have a system running FreeBSD 11.1-STABLE, PostgreSQL 9.6.8,Ja

Re: Query hitting empty tables taking 48 minutes

2018-06-07 Thread Robert Creager
> On Jun 7, 2018, at 3:34 PM, Tom Lane wrote: > > Robert Creager writes: >> Jun 7 17:24:21 blackpearl postgres[10670]: [7737-1] >> db=tapesystem,user=Administrator,app=[unknown],client=127.0.0.1 LOG: >> duration: 2903612.206 ms execute fetch from S_2037436/C

Re: Query hitting empty tables taking 48 minutes

2018-06-07 Thread Robert Creager
> On Jun 7, 2018, at 1:14 PM, Adrian Klaver wrote: > > On 06/07/2018 11:55 AM, Robert Creager wrote: >>> On Jun 7, 2018, at 12:40 PM, Adrian Klaver >> <mailto:adrian.kla...@aklaver.com>> wrote: >>> >>> On 06/07/2018 11:17 AM, Robert Creag

Re: Query hitting empty tables taking 48 minutes

2018-06-07 Thread Robert Creager
> On Jun 7, 2018, at 12:40 PM, Adrian Klaver wrote: > > On 06/07/2018 11:17 AM, Robert Creager wrote: >> I have a system running FreeBSD 11.1-STABLE, PostgreSQL 9.6.8,Java OpenJDK >> 1.8.0_131, jdbc 9.3-1104-jdbc41 which is exhibiting very bizarre behavior. >> A q

Query hitting empty tables taking 48 minutes

2018-06-07 Thread Robert Creager
I have a system running FreeBSD 11.1-STABLE, PostgreSQL 9.6.8,Java OpenJDK 1.8.0_131, jdbc 9.3-1104-jdbc41 which is exhibiting very bizarre behavior. A query is executing against a couple of tables that have 1 and 0 records in them. ds3.job_entry has 0 rows, ds3.blob has 1 row. If I execute