On Wed, Jan 31, 2018 at 04:34:18PM -0300, Claudio Freire wrote:
> In my experience playing with prefetch, e_i_c>0 interferes with kernel
> read-ahead. What you've got there would make sense if what postgres
> thinks will be random I/O ends up being sequential. With e_i_c=0, the
> kernel will optimi
On Tue, Feb 6, 2018 at 3:02 PM, Rick Otten wrote:
> Ooo. I wasn't aware of that option. (Learn something new every day!)
>
> Setting enable_seqscan=off takes one of the shorter queries I was working
> with from about 3 minutes to 300ms. This is a comparable performance
> improvement to where
Ooo. I wasn't aware of that option. (Learn something new every day!)
Setting enable_seqscan=off takes one of the shorter queries I was working
with from about 3 minutes to 300ms. This is a comparable performance
improvement to where I put a materialized view (with indexes) on top of the
materi
On Sun, Feb 04, 2018 at 11:04:56AM -0500, Rick Otten wrote:
> On Sun, Feb 4, 2018 at 10:35 AM, Tom Lane wrote:
>
> > Rick Otten writes:
> > > I'm wrestling with a very similar problem too - except instead of
> > official
> > > partitions I have a views on top of a bunch (50+) of unioned material
On Tue, 2018-02-06 at 15:31 +0100, Thomas Güttler wrote:
>
But one thing is still unclear. Imagine I see a peak in the chart. The peak
> was some hours ago. AFAIK sar has only the aggregated numbers.
>
> But I need to know details if I want to answer the question "Why?". The peak
> has gone
Am 05.02.2018 um 14:26 schrieb Andreas Kretschmer:
Am 05.02.2018 um 14:14 schrieb Thomas Güttler:
What do you suggest to get some reliable figures?
sar is often recommended, see
https://blog.2ndquadrant.com/in-the-defense-of-sar/.
Can you exclude other reasons like vacuum / vacuum freeze
