pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Andrew Hammond <andrew.george.hammond@gmail.com>
To: pgsql-hackers@postgresql.org
Subject: Re: using constraint based paritioning to fix EAV
Date: 18 Jul 2006 15:00:29 -0700
Message-ID: <1153260029.290428.151470@h48g2000cwc.googlegroups.com> (raw)
In-Reply-To: <1153257622.3681.1.camel@localhost.localdomain>
References: <1153238828.426611.113540@35g2000cwc.googlegroups.com>
	<bf05e51c0607181131s488e93bane69a37001ab0912@mail.gmail.com>
	<5a0a9d6f0607181344g530b4d09s393f3f0b46764fbe@mail.gmail.com>
	<1153257622.3681.1.camel@localhost.localdomain>


Hannu Krosing wrote:
> Ühel kenal päeval, T, 2006-07-18 kell 16:44, kirjutas Andrew Hammond:
> > On 7/18/06, Aaron Bono <postgresql@aranya.com> wrote:
> >         On 18 Jul 2006 09:07:08 -0700, Andrew Hammond
> >         <andrew.george.hammond@gmail.com> wrote:
> >
> >                 I have a client with the following EAV inspired
> >                 schema.
> >
> >                 CREATE TABLE many_tables (
> >                     table_id text primary key,        -- defines which
> >                 virtual table is
> >                 encoded
> >                     attribute1 text,
> >                     attribute2 text,
> >                     attribute3 text,
> >                     attribute4 text,
> >                     ...
> >                 );
>
> Maybe you can approach the problem from another end, and make the
> many_tables table the virtual one and all the others into real tables ?

The many_tables table already exists. It works about as poorly as you'd
expect. My goal is to migrate away from this attrocious design. My
question is how best to do that. I'd like to take advantage of table
partitioning and constraint based exclusion, but I can't figure out how
to do it since the underlying tables are heterogenous in nature.

Perhaps I'm going about this the wrong way though. I think I'll
partition based on table_id and leave the native storage in the crappy
text fields. Then create views of what should be the real, relational
tables. That lets the developers migrate and (I hope) eases the
performance burden somewhat. Once the code migration is complete I can
finalize the data move.




view thread (6+ messages)  latest in thread

Message-ID: <1153260029.290428.151470@h48g2000cwc.googlegroups.com>
Permalink:  ../1153260029.290428.151470@h48g2000cwc.googlegroups.com/
Also on:    postgresql.org/message-id/1153260029.290428.151470@h48g2000cwc.googlegroups.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-sql@postgresql.org
  Cc: andrew.george.hammond@gmail.com, pgsql-hackers@postgresql.org
  Subject: Re: using constraint based paritioning to fix EAV
  In-Reply-To: <1153260029.290428.151470@h48g2000cwc.googlegroups.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox