Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 1974 invoked from network); 2 Feb 2010 15:53:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 2 Feb 2010 15:53:48 -0000 Received: (qmail 35664 invoked by uid 500); 2 Feb 2010 15:53:48 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 35600 invoked by uid 500); 2 Feb 2010 15:53:48 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 35592 invoked by uid 99); 2 Feb 2010 15:53:48 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Feb 2010 15:53:48 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [63.82.107.6] (HELO red.amberpoint.com) (63.82.107.6) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Feb 2010 15:53:40 +0000 Received: from [127.0.0.1] (bpendleton-desk.edgility.com [10.10.12.164]) by red.amberpoint.com (8.13.8/8.13.8) with ESMTP id o12FrHNK021570 for ; Tue, 2 Feb 2010 07:53:17 -0800 Message-ID: <4B684A6D.8070303@amberpoint.com> Date: Tue, 02 Feb 2010 07:53:17 -0800 From: Bryan Pendleton User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Derby Discussion Subject: Re: pagesize for a given table References: <24CADBF1-6060-47D6-B535-648F67886832@tractionsoftware.com> <9907065E-85CC-4247-BA5C-5B819CE5924A@tractionsoftware.com> <4B683B7B.1080508@amberpoint.com> <74BA4DB6-07B2-4E32-850E-A21DE9E62690@tractionsoftware.com> In-Reply-To: <74BA4DB6-07B2-4E32-850E-A21DE9E62690@tractionsoftware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org David Parker wrote: > slowdowns that we have traced to this insert - a single insert taking several seconds That feels more like a locking issue than an I/O issue, to me. Perhaps you have some sort of rarely-run query which, when it runs, scans and processes the entire table, thus locking the table and preventing any insert into the table. Just a guess. thanks, bryan