Andres Freund writes:
> On 2014-07-01 15:20:37 -0400, Tom Lane wrote:
>> It seems like there are three, not mutually exclusive, ways we might
>> address this:
> But I think more importantly it's probably quite possible to hit a
> similar problem without ON COMMIT DROP relations. Say DISCARD TEMP
On 2014-07-01 15:20:37 -0400, Tom Lane wrote:
> Jeff Frost writes:
> >> On Jun 30, 2014, at 4:04 PM, Tom Lane wrote:
> >>> Did you check whether the locks were all on temp tables of the
> >>> ON COMMIT DROP persuasion?
>
> > And indeed it did catch up overnight and the lag increased shortly afte
Marc Mamin wrote:
> I/O througput decreased from 300MB/s to 160.
I don't have any experience with ext4 defrag tools, but just wanted
to point out that the difference in performance you cite above is
about the same as the difference between accessing data on the
outer (and usually first-filled) t
Dave Roberge writes:
> For example, running explain (analyze, buffers) with the query, 4/5 times we
> will see the following:
> -> Hash Join (cost=16385.76..103974.09 rows=523954 width=64) (actual
> time=532.634..4018.678 rows=258648 loops=1)
> Hash Cond: (p.a = c.c)
> Buffers: sh
Hi, I'm in the process of attempting to tune some slow queries. I came
across a scenario where I'm not entirely sure how I
might figure out why a node is taking awhile to process. I'm not concerned
with the query itself, we are working to figure
out how we can make it faster. But I was hoping s
Hello,
Has anyone some experience using defragmentation tools on Linux against
tablespaces ?
we are facing fragmentation problems with postgres instances having a few TB of
data.
( RAID 5 )
I/O througput decreased from 300MB/s to 160.
- We first moved some schemas to separate servers.
Afte
