Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 410EF634300 for ; Sat, 13 Mar 2010 17:18:19 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 01987-10 for ; Sat, 13 Mar 2010 21:18:04 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mail.postgresql.org (Postfix) with ESMTP id 38BB763278E for ; Sat, 13 Mar 2010 17:18:07 -0400 (AST) Received: by fxm22 with SMTP id 22so2321181fxm.34 for ; Sat, 13 Mar 2010 13:18:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent; bh=6+EB6Mi3Z8vPkkpMh1aKZV4Q/2BSgLNKbuLrEj6r+xo=; b=SuYklXc0csdvf6KZvo8iOd9V/JHqXg4qJRGFwNjGEVCmtqpYRe08NoPcLJewL7BM28 6Kv2NH0A3wiCLgcl2PYJgSW9r9kgeXVpPnCZx0Z5DRpSxbreEtDvkOfsnq7H4wh2tij+ YjP/az0rcI4uB6PEPxiqSfyPax2prW66geJDw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=a1gPEztoDr8bHdczSJEyQ7AxN5DvD6pVuRdP9YZSv9WEc5I2xuJ+cQgfCiBDOYjc31 e5xi0m0ccGHc6Pf8qXNllxLekO5u+W4C4izYpbdpzX6SH8rQ/VML8HPIF2djOnKs1Rf7 Uq36ykKUw/NlETzHKh5WxCEbG+QR9nrsQSOIY= Received: by 10.223.65.18 with SMTP id g18mr2820946fai.32.1268515086256; Sat, 13 Mar 2010 13:18:06 -0800 (PST) Received: from googlemail.com (port-87-193-148-114.static.qsc.de [87.193.148.114]) by mx.google.com with ESMTPS id 13sm1993927fxm.14.2010.03.13.13.18.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 13 Mar 2010 13:18:05 -0800 (PST) Received: by googlemail.com (nbSMTP-1.00) for uid 1100 (using TLSv1/SSLv3 with cipher RC4-MD5 (128/128 bits)) fkater@googlemail.com; Sat, 13 Mar 2010 22:17:43 +0100 (CET) Date: Sat, 13 Mar 2010 22:17:42 +0100 From: "fkater@googlemail.com" To: pgsql-performance@postgresql.org Subject: Deleting bytea, autovacuum, and 8.2/8.4 differences Message-ID: <20100313211742.GC2178@comppasch2> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5 tests=BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201003/131 X-Sequence-Number: 37956 Hi all, my posting on 2010-01-14 about the performance when writing bytea to disk caused a longer discussion. While the fact still holds that the overall postgresql write performance is roughly 25% of the serial I/O disk performance this was compensated for my special use case here by doing some other non-postgresql related things in parallel. Now I cannot optimize my processes any further, however, now I am facing another quite unexpected performance issue: Deleting rows from my simple table (with the bytea column) having 16 MB data each, takes roughly as long as writing them! Little more detail: * The table just has 5 unused int columns, a timestamp, OIDs, and the bytea column, no indices; the bytea storage type is 'extended', the 16 MB are compressed to approx. the half. * All the usual optimizations are done to reach better write through (pg_xlog on another disk, much tweaks to the server conf etc), however, this does not matter here, since not the absolute performance is of interest here but the fact that deleting roughly takes 100% of the writing time. * I need to write 15 rows of 16 MB each to disk in a maximum time of 15 s, which is performed here in roughly 10 seconds, however, now I am facing the problem that keeping my database tidy (deleting rows) takes another 5-15 s (10s on average), so my process exceeds the maximum time of 15s for about 5s. * Right now I am deleting like this: DELETE FROM table WHERE (CURRENT_TIMESTAMP - my_timestamp_column) > interval '2 minutes'; while it is planned to have the interval set to 6 hours in the final version (thus creating a FIFO buffer for the latest 6 hours of inserted data; so the FIFO will keep approx. 10.000 rows spanning 160-200 GB data). * This deletion SQL command was simply repeatedly executed by pgAdmin while my app kept adding the 16 MB rows. * Autovacuum is on; I believe I need to keep it on, otherwise I do not free the disk space, right? If I switch it off, the deletion time reduces from the average 10s down to 4s. * I am using server + libpq version 8.2.4, currently on WinXP. Will an upgrade to 8.4 help here? Do you have any other ideas to help me out? Oh, please... Thank You Felix