Samuel Gilbert writes:
> Here is a complete example demonstrating the issue I am encountering :
What seems to be happening is:
1. The parent table has a NOT NULL constraint on modificationDate.
2. parent_dispatcher_trigger does RETURN NEW, so the tuple will be
inserted into the parent table as
Hello everyone,
Here is a complete example demonstrating the issue I am encountering :
CREATE TABLE parent (
split INTEGER NOT NULL,
happiness INTEGER NOT NULL,
modificationDate TIMESTAMP NOT NULL
);
CREATE TABLE child_split1 ( CHECK (split = 1) ) INHERITS (parent);
CREATE TABLE child_s
On 2014-02-18 17:59:35 Tom Lane wrote:
> Samuel Gilbert writes:
> > All of this was done on PostgreSQL 9.2.0 64-bit compiled from the official
>
> > source. Significant changes in postgresql.conf :
> Why in the world are you using 9.2.0? You're missing a year and a half
> worth of bug fixes, so
> "The modification date must be updated if any row is modified in any way."
>
> If that is the case shouldn't the trigger also cover UPDATE?
You completely right about that! I actually have both configured, but I
focused only on the INSERT to try keep the length of my post as short as
possibl
On 02/18/2014 02:42 PM, Samuel Gilbert wrote:
On 2014-02-18 14:25:59 Adrian Klaver wrote:
On 02/18/2014 02:10 PM, Samuel Gilbert wrote:
I have data warehousing DB 2 fairly big tables : one contains about 200
million rows and the other one contains about 4 billion rows. Some
queries
are now tak
Samuel Gilbert writes:
> All of this was done on PostgreSQL 9.2.0 64-bit compiled from the official
> source. Significant changes in postgresql.conf :
Why in the world are you using 9.2.0? You're missing a year and a half
worth of bug fixes, some of them quite serious.
> INSERT ... RETURNING
On 2014-02-18 14:25:59 Adrian Klaver wrote:
> On 02/18/2014 02:10 PM, Samuel Gilbert wrote:
> > I have data warehousing DB 2 fairly big tables : one contains about 200
> > million rows and the other one contains about 4 billion rows. Some
> > queries
> > are now taking way too long to run (> 13 ho
On 02/18/2014 02:10 PM, Samuel Gilbert wrote:
I have data warehousing DB 2 fairly big tables : one contains about 200
million rows and the other one contains about 4 billion rows. Some queries
are now taking way too long to run (> 13 hours). I need to get these queries
to run in an hour or so.
