| From: | Rafal Pietrak <r(dot)pietrak(at)sm(dot)strop(dot)com(dot)pl> |
|---|---|
| To: | David Fetter <david(at)fetter(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: it's a feature, but it feels like a bug |
| Date: | 2018-02-08 18:02:23 |
| Message-ID: | e3a03ba9-7b89-ef3f-7d15-3c271b5dfa70@sm.strop.com.pl |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
W dniu 08.02.2018 o 05:51, David Fetter pisze:
> On Wed, Feb 07, 2018 at 10:26:50PM -0500, Tom Lane wrote:
>> Rafal Pietrak <r(dot)pietrak(at)sm(dot)strop(dot)com(dot)pl> writes:
[-------------]
>
> CREATE TABLE foo(b BOOLEAN, i INTEGER NOT NULL, t TEXT NOT NULL) PARTITION BY LIST (b);
> CREATE TABLE foo_true PARTITION OF foo (PRIMARY KEY(i, t)) FOR VALUES IN ('true');
> CREATE TABLE bar(foo_i INTEGER NOT NULL, foo_t TEXT NOT NULL, FOREIGN KEY(foo_i, foo_t) REFERENCES foo_true);
This is exactly my current setup.
It creates other problems with manageing my dataset, so I'm looking for
other ways to lay down the schema.
thenx,
-R
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2018-02-08 19:31:05 | Re: update tuple routing and triggers |
| Previous Message | Andres Freund | 2018-02-08 18:01:38 | Re: Proposal: partition pruning by secondary attributes |