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
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
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 th
[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
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,
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
> >>
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 so
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 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 vacuum takes on the order of a couple of weeks. The time between DB-wide vacuums is a little over a year, I believe.
Every coup
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
> -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
> dra
Hi,The documentation says that function blocks with exceptions are far costlier than without one.So if I need to implement an INSTEAD OF trigger (after checking for unique constraint violations) which way should I go ?
1. Get a table lock2. Use 'Select ... For Update' (which could be used to lock o
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 (cost=0.
Hello,
I do not understand, why Postgres very ofter starts execution from
sub-select instead of doing main select and then proceeding to "lite"
sub-selects. For example:
(example is quite weird, but it demonstrates the problem)
1. explain analyze select * from pg_proc offset 1500 limit 1;
"Limi
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
>
> Ie: select FeatureID from SIMPLE_TABLE where FeatureChromosomeName like
> 'chrX' and StartPosition > 1000500 and EndPosition < 200;
How about ( this assumes that StartPosition <= EndPosition ):
select FeatureID
from SIMPLE_TABLE
where FeatureChromosomeName llike 'chrX'
and StartPosition >
On Wed, 2006-11-01 at 14:15 -0500, Steven Flatt wrote:
> Here is a potential problem with the auto-vacuum daemon, and I'm
> wondering if anyone has considered this. To avoid transaction ID
> wraparound, the auto-vacuum daemon will periodically determine that it
> needs to do a DB-wide vacuum, whic
17 matches
Mail list logo
