Steinar,
which seems to make sense; you have one run of about 257ms, plus 514 runs
taking about 0.035ms each (ie. about 18ms), which should add up to become
about 275ms (which is close enough to the reality of 281ms).
Yep. The line that disturbed me was the bitmap index scan with a cost of
"a
I am using PHP's PDO PGSQL interface - I haven't read up enough on it
to determine whether a persistent connection can re-use server-side
prepared queries as an option. Anybody know?
It re-uses server-side prepared queries by default, if you are using the
PDOPrepare/PDOExecute stuff.
Chris
On Sun, 2005-23-10 at 21:36 -0700, Josh Berkus wrote:
> SELECT id INTO v_check
> FROM some_table ORDER BY id LIMIT 1;
>
> IF id > 0 THEN
>
> ... that says pretty clearly to code maintainers that I'm only interested in
> finding out whether there's any rows in the table, while making sure I
Karl,
> 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.
Well, there's always the destruction test: run each version of the function
10,000 times and see if there's an execution time difference.
Christian Paul B. Cosinas wrote:
Here is the result of “free” command” I am talking about.
What does this result mean?
I seem to recall the Linux man page for 'free' being most
unenlightening, so have a look at:
http://gentoo-wiki.com/FAQ_Linux_Memory_Management
(For Gentoo, but should
The preliminaries:
- PostgreSQL 8.1 beta 3, Debian experimental
- database has been VACUUMed FULL ANALYZE.
- a pg_dump -Fc exists at http://199.77.129.48/inet_test.db
- ia32 hardware with 2 GB physical memory and the following settings:
shared_buffers = 40960
temp_buffers = 16
total used free shared
buffers cached
Mem: 6192460 6137424
55036 0 85952 5828844
-/+ buffers/cache:
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 Mon, Oct 24, 2005 at 01:53:59AM +0200, Guillaume Smet wrote:
> I don't understand why I have the Nested Loop at line 19 with an actual
> time of 254.292..257.328 because I can't find anywhere the line taking
> this 254 ms.
You don't have a nested loop with that time; however, you have
> ->
Hi all,
I'm currently testing PostgreSQL 8.1 beta3 and I have a problem with a
EXPLAIN ANALYZE output. You can find it attached.
I don't understand why I have the Nested Loop at line 19 with an actual
time of 254.292..257.328 because I can't find anywhere the line taking
this 254 ms. Is it a
Hi Craig,
Thank you very much for your response.
It really covered a great point.
Thank you,
Kishore.
On 10/23/05, Craig A. James <[EMAIL PROTECTED]> wrote:
> We are facing a* critical situation because of the performance of the> **database** .* Even a basic query like select count(*) from
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.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broad
"Craig A. James" <[EMAIL PROTECTED]> writes:
> MIN() and MAX() -- These are surprisingly slow, because they seem to do a
> full table scan EVEN ON AN INDEXED COLUMN! I don't understand why, but
> happily there is an effective substitute:
>select mycolumn from mytable order by mycolumn limit
On Sun, Oct 23, 2005 at 09:31:44AM -0700, Craig A. James wrote:
> COUNT() -- There is no good substitute. What I do is create a new column,
> "ROW_NUM" with an auto-incrementing sequence. Every time I insert a row,
> it gets a new value. Unfortunately, this doesn't work if you ever delete a
>
Dnia 23-10-2005, nie o godzinie 09:31 -0700, Craig A. James napisał(a):
> MIN() and MAX() -- These are surprisingly slow, because they seem to do a
> full table scan EVEN ON AN INDEXED COLUMN!
In 8.1 this is no true, see the changelog.
> I don't understand why, but happily there is an effective
We are facing a* critical situation because of the performance of the
**database** .* Even a basic query like select count(*) from
bigger_table is taking about 4 minutes to return.
Several other replies have mentioned that COUNT() requires a full table scan, but this point can't be emphasized
On Thu, Oct 20, 2005 at 12:37:25AM -0400, Tom Lane wrote:
> That mdb_gruppekobling_transitiv_tillukning function looks awfully
> grotty ... how many rows does it return, and how long does it take to
> run by itself? How often does its temp table get vacuumed? A quick
> band-aid might be to use TR
On Sun, 23 Oct 2005, Kishore B wrote:
> We need to insert into the bigger table almost for every second , through
> out the life time. In addition, we receive at least 200,000 records a day at
> a fixed time.
>
> We are facing a* critical situation because of the performance of the **
> database*
19 matches
Mail list logo
