Return-Path: 
 <dev-return-11761-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org>
Delivered-To: apmail-couchdb-dev-archive@www.apache.org
Received: (qmail 30597 invoked from network); 19 Sep 2010 12:28:28 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 19 Sep 2010 12:28:28 -0000
Received: (qmail 70205 invoked by uid 500); 19 Sep 2010 12:28:28 -0000
Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org
Received: (qmail 69848 invoked by uid 500); 19 Sep 2010 12:28:25 -0000
Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@couchdb.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@couchdb.apache.org>
List-Post: <mailto:dev@couchdb.apache.org>
List-Id: <dev.couchdb.apache.org>
Reply-To: dev@couchdb.apache.org
Delivered-To: mailing list dev@couchdb.apache.org
Received: (qmail 69833 invoked by uid 99); 19 Sep 2010 12:28:24 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 19 Sep 2010 12:28:24 +0000
X-ASF-Spam-Status: No, hits=0.7 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [80.244.253.218] (HELO mail.traeumt.net) (80.244.253.218)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 19 Sep 2010 12:28:16 +0000
Received: from [192.168.178.25] (brln-4d0cd8e4.pool.mediaWays.net
 [77.12.216.228])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by mail.traeumt.net (Postfix) with ESMTPSA id 298331B5C2
	for <dev@couchdb.apache.org>; Sun, 19 Sep 2010 14:27:54 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: Re: Database-level statistics/on-disk file names
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: <AANLkTi=PpfRdNZ2jTEe1ARW43KG3QpJoXzmzQV8Yyh8z@mail.gmail.com>
Date: Sun, 19 Sep 2010 14:27:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <577410FC-950F-4B9A-90EA-A2BF3B40CAF8@apache.org>
References: <AANLkTi=PpfRdNZ2jTEe1ARW43KG3QpJoXzmzQV8Yyh8z@mail.gmail.com>
To: dev@couchdb.apache.org
X-Mailer: Apple Mail (2.1081)


On 17 Sep 2010, at 10:10, Dirkjan Ochtman wrote:

> Hi there,
>=20
> I'd like to be able to determine how much disk space the index for a
> certain ddoc takes. Is there any easy way of doing that?

 curl $COUCH/db/_design/name/_info
=
{"name":"db","view_index":{"signature":"431517a0e7decdaa8a97d0dc9ffd7412",=
"language":"javascript","disk_size":51,"updater_running":true,"compact_run=
ning":false,"waiting_commit":false,"waiting_clients":0,"update_seq":0,"pur=
ge_seq":0}}

The `signature` field corresponds to the .db_design/`signature`.view =
file.

--

> Relatedly, would it be possible to rejigger the on-disk layout a
> little bit to make the filenames easier to understand? For example, we
> now have:
>=20
> /foo.couch
> /.foo_design/<big-hash>.view
> /.foo_temp
>=20
> It would seem nicer to have, e.g.
>=20
> /foo/data.couch
> /foo/users-<big-hash>.view
> /foo/.temp

I understand that it may seem nice to have everything related to a=20
databases in a single directory, for say moving things around but=20
practically, the current format is just as easy to script as the =
proposed=20
version. What other reasons do you see that would improve with=20
the proposed version?

In addition, creating and deleting databases would no longer be=20
atomic (mkdir & fopen), but I'm not sure that's a hard requirement.=20
I know the current model includes some very finicky details about=20
deleting and renaming files on Windows which would need to be=20
taken into consideration when changing the filesystem structure.

> (Unless maybe you want to be able to rename design docs without having
> to re-index, but I think even that would be manageable.)

This is a required feature :)

> This would also make index size fairly transparent.

I don't see how that's any different with either or any filesystem =
layout.

> Semi-relatedly, has anyone taken a swing at reflecting /_stats into a
> Futon page?

Oh I'd *love* to see that :)

Cheers
Jan
--=20