Missed the 2nd part of Claudio's reply here.
I actually tried different settings of work_mem up to 512M which didn't make
any difference.
Check constraints appear to be there:
nms=# \d syslog_201304
Table "public.syslog_201304"
Column |Type
Thanks for all the advice here. I'll look at setting up something in a test
environment and play with the clustering. Testing how other queries perform
against the clustering, also.
Thank you!
Sam
-Original Message-
From: David Kerr [mailto:d...@mr-paradox.net]
Sent: Friday, 4 Octo
On Thu, Oct 03, 2013 at 09:20:52AM -0700, David Kerr wrote:
- On Thu, Oct 03, 2013 at 01:47:29AM +, Samuel Stearns wrote:
- - Thanks, Claudio:
- -
- - http://explain.depesz.com/s/WJQx
-
- You're spending a lot of time in the hash join which can kill a system with
- low ram.
-
- You may, just
On Thu, Oct 03, 2013 at 01:47:29AM +, Samuel Stearns wrote:
- Thanks, Claudio:
-
- http://explain.depesz.com/s/WJQx
You're spending a lot of time in the hash join which can kill a system with
low ram.
You may, just for fun, want to try the query with enable_hashjoin=false.
--
Sent via pg
On Thu, Oct 03, 2013 at 04:19:29AM +, Samuel Stearns wrote:
> Thanks, Claudio.
>
> I'll have a look at the clustering.
>
> We have also noticed that the same query with a datetime range of 3 hours
> (rather than 4 months) runs in just 30 seconds:
>
> AND datetime <= '2013-10-03 10:03:49'
>
On 03/10/2013 03:17, Samuel Stearns wrote:
> The last part, the EXPLAIN, is too big to send. Is there an alternative
> way I can get it too you, other than chopping it up and sending in
> multiple parts?
The usual way is via http://explain.depesz.com/ .
signature.asc
Description: OpenPGP digi
