Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id E41EE9F9CE9 for ; Sun, 19 Aug 2007 17:42:39 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 79283-03 for ; Sun, 19 Aug 2007 17:42:37 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [129.241.93.19]) by postgresql.org (Postfix) with ESMTP id 2E24E9F9591 for ; Sun, 19 Aug 2007 17:42:36 -0300 (ADT) Received: from trofast.ipv6.sesse.net ([2001:700:300:1803:20e:cff:fe36:a766] helo=trofast.sesse.net) by cassarossa.samfundet.no with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1IMrbW-0000ed-Ol for pgsql-performance@postgresql.org; Sun, 19 Aug 2007 22:42:35 +0200 Received: from root by trofast.sesse.net with local (Exim 4.67) (envelope-from ) id 1IMrbW-0006i9-73 for pgsql-performance@postgresql.org; Sun, 19 Aug 2007 22:42:34 +0200 Date: Sun, 19 Aug 2007 22:42:34 +0200 From: "Steinar H. Gunderson" To: pgsql-performance@postgresql.org Subject: Re: schema design question Message-ID: <20070819204234.GA25727@uio.no> Mail-Followup-To: pgsql-performance@postgresql.org References: <20070819181216.GK28490@fetter.org> <20070819182658.GC25214@uio.no> <20070819184115.GL28490@fetter.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20070819184115.GL28490@fetter.org> X-Operating-System: Linux 2.6.20.4 on a x86_64 X-Message-Flag: Outlook? --> http://www.mozilla.org/products/thunderbird/ User-Agent: Mutt/1.5.16 (2007-06-11) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200708/203 X-Sequence-Number: 26333 On Sun, Aug 19, 2007 at 11:41:15AM -0700, David Fetter wrote: > Unless your records are huge, that's a tiny database, where tiny is > defined to mean that the whole thing fits in main memory with plenty > of room to spare. I guarantee that performance will crash right > through the floor as soon as any table no longer fits in main memory. Sure, it fits into memory; however, it isn't used so often, though, so it's frequently not in the cache when it's needed. You are completely right in that it's much slower from disk than from RAM :-) The question is, of course, how to best store something like the EXIF information _without_ using EAV. I could separate out the few fields I normally use into a horizontal (ie. standard relational) table, but it seems sort of... lossy? Another possible approach is to keep the EAV table around for completeness in addition to the few fields I need, but then you do of course get into normalization issues. /* Steinar */ -- Homepage: http://www.sesse.net/