On Tue, 2006-10-31 at 18:18 -0500, John Major wrote:
#I am a biologist, and work with large datasets (tables with millions of
rows are common).
#These datasets often can be simplified as features with a name, and a
start and end position (ie: a range along a number line. GeneX is on
Nikolay Samokhvalov wrote:
2. explain analyze select
*,
(select typname from pg_type where pg_type.oid=pg_proc.prorettype limit 1)
from pg_proc offset 1500 limit 1;
Limit (cost=8983.31..8989.30 rows=1 width=365) (actual
time=17.648..17.649 rows=1 loops=1)
- Seq Scan on pg_proc
-Original Message-
From: [EMAIL PROTECTED]
Nikolay Samokhvalov
What should I do to make Postgres work properly in such cases (I have
a lot of similar queries; surely, they are executed w/o seqscans, but
overall picture is the same - I see that starting from sub-selects
Hi all,
I've got a script (perl, in case it matters) that I need to run once
a month to prepare statements. This script queries and updates the
database a *lot*. I am not concerned with the performance of the SQL
calls so much as I am about the impact it has on the server's load.
Is there a
Sorry, I think there's a misunderstanding here. Our system is not doing near that number of transactions per second. I meant that the duration of a single DB-wide vacuumtakes on the order of acouple of weeks. The time between DB-wide vacuums is a little over a year, I believe.
Every couple of
On Thu, 2006-11-02 at 09:14, Madison Kelly wrote:
Hi all,
I've got a script (perl, in case it matters) that I need to run once
a month to prepare statements. This script queries and updates the
database a *lot*. I am not concerned with the performance of the SQL
calls so much as I am
Scott Marlowe wrote:
On Thu, 2006-11-02 at 09:14, Madison Kelly wrote:
Hi all,
I've got a script (perl, in case it matters) that I need to run once
a month to prepare statements. This script queries and updates the
database a *lot*. I am not concerned with the performance of the SQL
calls
On Thu, 2006-11-02 at 09:25, Madison Kelly wrote:
Scott Marlowe wrote:
On Thu, 2006-11-02 at 09:14, Madison Kelly wrote:
Hi all,
I've got a script (perl, in case it matters) that I need to run once
a month to prepare statements. This script queries and updates the
database a *lot*.
Steven Flatt wrote:
Sorry, I think there's a misunderstanding here. Our system is not doing
near that number of transactions per second. I meant that the duration of a
single DB-wide vacuum takes on the order of a couple of weeks. The time
between DB-wide vacuums is a little over a year, I
[Madison Kelly - Thu at 10:25:07AM -0500]
Will the priority of the script pass down to the pgsql queries it calls?
I figured (likely incorrectly) that because the queries were executed by
the psql server the queries ran with the server's priority.
I think you are right, and in any case, I
Dave Dutcher wrote:
-Original Message-
From: [EMAIL PROTECTED]
Nikolay Samokhvalov
What should I do to make Postgres work properly in such cases (I have
a lot of similar queries; surely, they are executed w/o seqscans, but
overall picture is the same - I see that starting
On Oct 27, 2006, at 2:07 PM, Tom Lane wrote:
8.2, but in existing releases I can't see much you can do about it
except REINDEX when things get slow.
This will be so nice for me. I have one huge table with a massive
amount of churn and bulk deletes. I have to reindex it once every
other
Robins wrote:
Hi,
The documentation says that function blocks with exceptions are far
costlier than without one.
I recommend against using exceptions. There is a memory leak in the
exception handler that will cause headaches if it is called many times
in the transaction.
In plpgsql, I
13 matches
Mail list logo
