pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed

From: Christoph Berg <myon@debian.org>
To: Joao Junior <jcoj2006@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Delete huge Table under XFS
Date: Thu, 19 Sep 2019 19:27:13 +0200
Message-ID: <20190919172713.GA6865@msg.df7cb.de> (raw)
In-Reply-To: <CABnPa_hdHsdypn7HtXU81B9HcrVcimotnwfzE-MWwO1etWYJzA@mail.gmail.com>
References: <CABnPa_h2f5342mF6yM9pAR1=nV24hKwiBAXhmiS9zOEKmvUQAg@mail.gmail.com>
	<357e7bd3-1b40-180c-14ce-7911229b5efb@a-kretschmer.de>
	<CABnPa_hdHsdypn7HtXU81B9HcrVcimotnwfzE-MWwO1etWYJzA@mail.gmail.com>

Re: Joao Junior 2019-09-19 <CABnPa_hdHsdypn7HtXU81B9HcrVcimotnwfzE-MWwO1etWYJzA@mail.gmail.com>
> A table with 800 gb means 800 files of 1 gb. When I use truncate or drop
> table,  xfs that is a log based filesystem,  will write lots of data in its
> log and this is the problem. The problem is not postgres, it is the way
> that xfs works with big files , or being more clear, the way that it
> handles lots of files.

Why is the runtime of a DROP TABLE command important? Is anything
waiting for it?

Christoph

view thread (5+ messages)  latest in thread

Message-ID: <20190919172713.GA6865@msg.df7cb.de>
Permalink:  ../20190919172713.GA6865@msg.df7cb.de/
Also on:    postgresql.org/message-id/20190919172713.GA6865@msg.df7cb.de

copy link · copy postgr.es

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: myon@debian.org, jcoj2006@gmail.com
  Subject: Re: Delete huge Table under XFS
  In-Reply-To: <20190919172713.GA6865@msg.df7cb.de>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox