X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 96026DB32B for ; Sat, 29 Oct 2005 10:38:31 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 01941-05 for ; Sat, 29 Oct 2005 13:38:27 +0000 (GMT) Received: from ore.jhcloos.com (ore.jhcloos.com [64.240.156.239]) by svr1.postgresql.org (Postfix) with ESMTP id C04F1DB325 for ; Sat, 29 Oct 2005 10:38:27 -0300 (ADT) Received: from lugabout.jhcloos.org (host-69-48-15-45.roc.choiceone.net [69.48.15.45]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "lugabout.jhcloos.org", Issuer "ca.jhcloos.com" (verified OK)) by ore.jhcloos.com (Postfix) with ESMTP id EE7121C591 for ; Sat, 29 Oct 2005 08:38:24 -0500 (CDT) Received: by lugabout.jhcloos.org (Postfix, from userid 500) id 10EE12228AA; Sat, 29 Oct 2005 13:38:09 +0000 (GMT) From: James Cloos To: pgsql-sql@postgresql.org Subject: Two tables or three? Copyright: Copyright 2005 James Cloos X-Hashcash: 1:21:051029:pgsql-sql@postgresql.org::pggNhLrIlwEHDUVD:00000000000000000000000000000000000003As3 Date: Sat, 29 Oct 2005 09:38:08 -0400 Message-ID: Lines: 38 User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/23.0.0 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0 required=5 tests=[none] X-Spam-Score: 0 X-Spam-Level: X-Archive-Number: 200510/391 X-Sequence-Number: 23244 I'm designing a schema for an app that requires two large blobs per row. Given that querying does not hit those, I presume it is beneficial to move the blobs out of the main table. But should each blob be in its own table, or should they go into a single, three column table? The main table does need a sequential primary key column, so I expect to use that value to reference the blobs by using it as a primary key in the blobs' table(s). Each row will have an associated first_blob, virtually all of them with also have an associated second_blob. The usage scenario has the user doing some queries on the data in the main table and manually selecting one or more rows at a time; upon selection the app will need to grab the blobs and show those. Most of the time both will be grabbed by interactive users, but noninteractive clients may only care about the first blob. The blob table(s) will need to CASCADE row deletions from the first table. I expect to have the ui flag deletable rows and use a vacuum-like process to do the actual deletions. (In part this will give some opportunity to 'un-delete', but I also presume a performance benefit. Yes?) Given that usage pattern, is there any benefit for one or two blob-specific table(s)? Or for that matter any benefit for splitting them out at all? This will be on 8.1. (Devel work is being done on the current beta.) Thanks, -JimC -- James H. Cloos, Jr.