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 wri
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 r
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 yo
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 theref
On 06/28/2005 01:40:56 AM, Tom Lane wrote:
"Karl O. Pinc" <[EMAIL PROTECTED]> writes:
> I have a query
> select 1
> from census
> where date < '1975-9-21' and sname = 'RAD' and status != 'A'
> limit 1;
> Explai
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 wou
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
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 06:33:03 PM, Michael Fuhr wrote:
On Mon, Jun 27, 2005 at 11:30:45PM +, Karl O. Pinc wrote:
>
> Short of that I think I'm going to be reduced to
> writing a C function that returns the real
> system time so I can spatter my code with
> RAISE statements
Hi,
I'm having a hard time finding the poorly performing
statements in my plpgsql procedures, many of which
are triggers. Am I missing something?
I can get the query plans by starting up a new
connection and doing:
SET DEBUG_PRINT_PLAN TO TRUE;
SET CLIENT_MIN_MESSAGES TO DEBUG1;
And then runnin
http://www.postgresql.org/docs/8.0/static/indexes-examine.html
Says:
"If you do not succeed in adjusting the costs to be more
appropriate, then you may have to resort to forcing index
usage explicitly."
Is there a way to force a query to use a particular index?
If not, what does this sentence m
Postgresql 8.0.3
Hi,
I have a query
select 1
from census
where date < '1975-9-21' and sname = 'RAD' and status != 'A'
limit 1;
Explain analyze says it always uses the index made by:
CREATE INDEX census_date_sname ON census (date, sname);
this is even after I made the index:
CREATE IN
12 matches
Mail list logo
