Hi,
I am interested in how to speed up storage. About 1000
or more inserts may need to be performed at a time ,
and before each insert I need to look up its key from
the reference table. So each insert is actually a
query followed by an insert.
The tables concerned are :
CREATE TABLE referencet
> > Consider the following tables/fields:
> > table "person": fields "p_id", "p_name".
> > table "person_attribute": fields "a_id", "a_name".
> > table "person_data": fields "d_person_id", "d_attribute_id",
> > "d_value".
> >
> > Also consider that a person may not have data related to all possibl
Andreas Tille wrote:
>
> On Fri, 25 Aug 2000, Tom Lane wrote:
>
> > I think you are getting burnt by premature constant folding --- see
> > nearby discussion of how to define a column default that gives the
> > time of insertion. You need to write this as
> > NEW.ChangedAt := now();
> >
On Fri, 25 Aug 2000, hlefebvre wrote:
> Tom Lane wrote:
> > NEW.ChangedAt := now();
> > to prevent the system from reducing timestamp('now') to a constant
> > when the function is first executed.
> >
> > regards, tom lane
> yep you're right :
You both are comple
Tom Lane wrote:
>
> Andreas Tille <[EMAIL PROTECTED]> writes:
> >> NEW.ChangedAt := timestamp(''now'');
>
> > This avoids the error message, but doesn't have any effect to the value
> > of ChangedAt. It just remains the same as CreatedAt :-(.
>
> I think you are getting burnt by premature co
On Fri, 25 Aug 2000, Tom Lane wrote:
> I think you are getting burnt by premature constant folding --- see
> nearby discussion of how to define a column default that gives the
> time of insertion. You need to write this as
> NEW.ChangedAt := now();
> to prevent the system from reducing tim
Andreas Tille <[EMAIL PROTECTED]> writes:
>> NEW.ChangedAt := timestamp(''now'');
> This avoids the error message, but doesn't have any effect to the value
> of ChangedAt. It just remains the same as CreatedAt :-(.
I think you are getting burnt by premature constant folding --- see
nearby discu
Andreas Tille wrote:
>
> On Fri, 25 Aug 2000, hlefebvre wrote:
>
> > No I suppose that the problem is the identifier "changedat" is unknown.
> >
> > You must probably prefix it : NEW.changedat
> >
> > CREATE FUNCTION changed_at_timestamp() RETURNS OPAQUE AS '
> > BEGIN
> > NEW.C
On Fri, 25 Aug 2000, hlefebvre wrote:
> No I suppose that the problem is the identifier "changedat" is unknown.
>
> You must probably prefix it : NEW.changedat
>
> CREATE FUNCTION changed_at_timestamp() RETURNS OPAQUE AS '
> BEGIN
> NEW.ChangedAt := timestamp(''now'');
>
Andreas Tille wrote:
>
> On Wed, 23 Aug 2000, hlefebvre wrote:
>
> > Yes. The keywords NEW / OLD are available only in triggers
> > see
> > http://www.postgresql.org/users-lounge/docs/7.0/user/c40874113.htm#AEN4286
> Well, I believe that, but
>
> CREATE FUNCTION changed_at_timestamp() RETURNS
On Wed, 23 Aug 2000, hlefebvre wrote:
> Yes. The keywords NEW / OLD are available only in triggers
> see
> http://www.postgresql.org/users-lounge/docs/7.0/user/c40874113.htm#AEN4286
Well, I believe that, but
CREATE FUNCTION changed_at_timestamp() RETURNS OPAQUE AS '
BEGIN
ChangedAt
On Thu, 24 Aug 2000, Hiroshi Inoue wrote:
> Hmm,Andreas's original function seems to contain other statements.
> If the function contains DML statements for the table Temp_Num_Table,
> it wouldn't work properly. i.e 1st call would work but 2nd call woudn't.
That's the problem. I'm in the process
12 matches
Mail list logo
