Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 17880 invoked from network); 11 Feb 2009 11:43:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Feb 2009 11:43:46 -0000 Received: (qmail 67772 invoked by uid 500); 11 Feb 2009 11:43:43 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 67734 invoked by uid 500); 11 Feb 2009 11:43:42 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 67723 invoked by uid 99); 11 Feb 2009 11:43:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Feb 2009 03:43:42 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [83.97.50.139] (HELO jan.prima.de) (83.97.50.139) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Feb 2009 11:43:34 +0000 Received: from dahlia.lan (f053000042.adsl.alicedsl.de [::ffff:78.53.0.42]) (AUTH: LOGIN jan, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by jan.prima.de with esmtp; Wed, 11 Feb 2009 11:43:10 +0000 Message-Id: From: Jan Lehnardt To: user@couchdb.apache.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: A permanent view for user-entered query with complex boolean expressions? Date: Wed, 11 Feb 2009 12:42:38 +0100 References: X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org On 10 Feb 2009, at 23:10, Barry Wark wrote: > On Tue, Feb 10, 2009 at 12:34 PM, Chris Anderson > wrote: >> On Tue, Feb 10, 2009 at 12:09 PM, Paul Davis >> wrote: >>> >>> Trunk has support for streaming writes when a Content-Length >>> header is >>> present. Chris Anderson was just working the other day on streaming >>> writes to disk in the absence of a Content-Length header. That >>> basically means that if your HTTP client sends a content-length >>> header, the sky's the limit. If you don't send a Content-Length >>> header, you'll be limited by the available RAM on the machine >>> running >>> CouchDB until Chris finishes his patch. >> >> Just to clear up, currently attachment PUTs without Content-Length >> headers are rejected. I think that we fixed the RAM buffering issue >> after all: >> >> https://issues.apache.org/jira/browse/COUCHDB-189 (fixed) >> >> So if you know the length of the attachment, PUT should work for you >> no matter how big it is. > > Very cool. What about reading the attachment? Is there a significant > performance hit for streaming the attachment out of the database as > opposed to reading the data directly out of a separate file? We don't use sendfile() yet, so it is not optimal, but overhead is minimal. Cheers Jan --