My idea is that DRI will help during the the JOINs I'll need to make later.
Creating a trigger to check the consistence would not help for that case, unless my idea is wrong. In which case I'd follow the great Merlin's hint. So the question is now: do DRI impact on JOINs efficiency? What'd be the gain? The table in question should easily go 20+M rows, possibly up to 50+M a year. The partitioning would ensure about 2M rows per partition and the trigger should work accordingly to this (dynamic) schema. So, along with the loss of efficiency due to the trigger I also would get some other loss because of an external table needed for the partitioning. On Friday December 19 2008 17:15:56 Merlin Moncure wrote: > On Fri, Dec 19, 2008 at 6:04 AM, Reg Me Please <regmeple...@gmail.com> wrote: > > Hi all. > > > > I need to implement something very similar to temporal table partitioning > > as described in the documentation at chapter 5.9. > > > > My issues come from the fact that I have other tables that references > > (FKs) to the table(s) to be partitioned. Those references are enforced by > > means of DRI statements (REFERENCES ...). > > > > As the table containing the referenced data will not be a single table, > > will I be forced to drop DRI? > > The referencing table(s) don't need to be partitioned, though and have > > also other FKs to other tables. > > > > Is there any other solution as I would keep DRI? > > Write a trigger. > > merlin -- Fahrbahn ist ein graues Band weisse Streifen, grüner Rand -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
