From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | bubba postgres <bubba(dot)postgres(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Odd performance difference in check constraint : SQL(slow) vs plpgsql(fast) |
Date: | 2011-06-17 23:25:16 |
Message-ID: | 742.1308353116@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
bubba postgres <bubba(dot)postgres(at)gmail(dot)com> writes:
> This is the reverse of what I thought I would find.
> In short my check constraint is extracting the epoch from a start timestamp,
> and an end timestamp to get the number of seconds difference.
> It then uses this number to check the array_upper() of an array to make sure
> it's the proper size
> The SQL version uses a case statement, and the plpgsql uses an IF/ELSE
> In a particular insert test
> The plpgsql version adds 1 second over the no constraints case.
> the sql version adds 10 seconds over the no constraints case.
> Why would this be?
It would not likely be faster unless it can be inlined, and maybe not
even then, because of plan caching effects (plpgsql is a lot better
about that). In this particular case, I'm suspicious whether all the
operations are immutable; if they aren't, the marking of the function
as immutable will definitely prevent inlining.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2011-06-18 03:10:10 | Re: merge in postgres trigger function |
Previous Message | Mike Christensen | 2011-06-17 23:08:49 | Re: Constraint to ensure value does NOT exist in another table? |