On 10/23/2005 04:02:35 PM, Josh Berkus wrote:
Karl,
PERFORM 1 FROM foo;
IF FOUND THEN ...
is any slower than:
PERFORM 1 FROM foo LIMIT 1;
IF FOUND THEN ...
I'm wondering in what context it makes sense to call PERFORM on a
constant.
If you want to find out if the table has any rows.
On 10/23/2005 04:02:35 PM, Josh Berkus wrote:
I'm wondering in what context it makes sense to call PERFORM on a
constant.
I like to write PERFORMs that return a constant when
selecting from a table. It emphasizes that the
selection is being done for its side effects.
(Programs should be
On 10/22/2005 04:15:25 PM, Kishore B wrote:
Can any you please suggest the best configuration to satisfy the above
requirements?
You've increased shared memory buffers, told the kernel
to allow more shared memory (lots), and otherwise increased
the parameters associated with memory?
If so
Hi,
I'm wondering if the plpgsql code:
PERFORM 1 FROM foo;
IF FOUND THEN ...
is any slower than:
PERFORM 1 FROM foo LIMIT 1;
IF FOUND THEN ...
Seems like it _could_ be smart enough to know that
1) It's selecting from a real table and not a function
2) GET DIAGNOSTICS is not used
and
On 06/27/2005 05:37:41 PM, Josh Berkus wrote:
Karl,
Seems to me that when there's a constant value in the query
and an = comparision it will always be faster to use the (b-tree)
index that's ordered first by the constant value, as then all
further
blocks are guarenteed to have a higher
On 06/27/2005 08:34:19 PM, Michael Fuhr wrote:
On Tue, Jun 28, 2005 at 01:54:08AM +, Karl O. Pinc wrote:
On 06/27/2005 06:33:03 PM, Michael Fuhr wrote:
See timeofday().
That only gives you the time at the start of the transaction,
so you get no indication of how long anything
On 06/27/2005 09:36:51 PM, Karl O. Pinc wrote:
I'm doing this in a torture test script, loading data.
Every fibnocci number of rows * 100 I VACCUM ANALYZE.
So, 100, 200, 300, 500, 800, etc.
(And of course disconnect my client and re-connect so
as to use the new statistics. sure would
