X-Original-To: pgsql-sql-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 5B2E49FA5F0 for ; Tue, 20 Jun 2006 10:48:10 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 40089-03 for ; Tue, 20 Jun 2006 10:48:04 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey- Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by postgresql.org (Postfix) with ESMTP id A336A9FA219 for ; Tue, 20 Jun 2006 10:48:04 -0300 (ADT) Received: by nf-out-0910.google.com with SMTP id i2so1242360nfe for ; Tue, 20 Jun 2006 06:48:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ArF9AB3uOeuMxxJbxEwQ0x1ZPgkVwnibKa62Isy8h5qrF21wqWVqb209MoTBNAjG6Y9XClyHCFMJHXn9AcmG0iZXlW7Zm1guAmdRAsZqQ2fu89RfKFly/kA1bzrYx9bC5njpbFNcsfjlK6PASriuS5wnZXoH21h3LnDuNruba1Y= Received: by 10.49.72.16 with SMTP id z16mr5655225nfk; Tue, 20 Jun 2006 06:48:02 -0700 (PDT) Received: by 10.48.218.9 with HTTP; Tue, 20 Jun 2006 06:48:02 -0700 (PDT) Message-ID: <5d0f60990606200648m3ff1e8b1h79e6fdb86ec97ac8@mail.gmail.com> Date: Tue, 20 Jun 2006 15:48:02 +0200 From: "Dirk Jagdmann" To: "Daniel CAUNE" Subject: Re: keeping last 30 entries of a log table Cc: "Jeff Frost" , pgsql-sql@postgresql.org In-Reply-To: <0J1400MJFAIHSME0@VL-MH-MR002.ip.videotron.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0J1400MJFAIHSME0@VL-MH-MR002.ip.videotron.ca> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/229 X-Sequence-Number: 25465 > Column id should be indexed indeed. Anyway, I'm not sure about any performance improvement using that last method, as the most consuming operation might be the DELETE operation, not really the SELECT operation, when dealing with a huge volume of data. why worry, there are a maximum of 30 Entries in this table anyway. So even the most unoptimized select and delete combinations should be very fast... -- ---> Dirk Jagdmann ----> http://cubic.org/~doj -----> http://llg.cubic.org