Using a functional index you can define an index around the way you
access the data. There is no faster or better way to do it...this is a
mathematical truth, not a problem with the planner. Why not use the
right tool for the job? A boolean index is super-efficient both in disk
space and
hi,
has anyone compile Postgres with Intel compiler ?
Does it exist a substantial gain of performance ?
--
Jean-Max Reymond
CKR Solutions
http://www.ckr-solutions.com
---(end of broadcast)---
TIP 6: Have you searched our list archives?
Hi all!
I'm new here, so hello to everybody!
I'm in a deep truble using postgesSQL 7.2.0 on a low-end pc with SUSE 8. I'm
using some databases from that pc through odbc (7.3.200). Until now i had no
problems with this solution, everithing worked fine. But today i wrote a
small app, that
I'm new here, so hello to everybody!
I'm in a deep truble using postgesSQL 7.2.0 on a low-end pc with SUSE 8.
I'm
using some databases from that pc through odbc (7.3.200). Until now i had
no
problems with this solution, everithing worked fine. But today i wrote a
small app, that
We have a web based application with data that is updated daily. The
biggest bottleneck occurs when we try to update
one of the tables. This table contains 58,000 rows and 62 columns, and
EVERY column is indexed. Every column is
queryable (?) by the users through the web interface so we are
What is the datatype of the id column?
-tfo
On Aug 31, 2004, at 1:11 PM, Ron St-Pierre wrote:
We have a web based application with data that is updated daily. The
biggest bottleneck occurs when we try to update
one of the tables. This table contains 58,000 rows and 62 columns, and
EVERY column
On Tue, Aug 31, 2004 at 11:11:02AM -0700, Ron St-Pierre wrote:
We have a web based application with data that is updated daily. The
biggest bottleneck occurs when we try to update
one of the tables. This table contains 58,000 rows and 62 columns, and
EVERY column is indexed.
That is usually
Thomas F. O'Connell wrote:
What is the datatype of the id column?
The id column is INTEGER.
Ron
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Steinar H. Gunderson wrote:
On Tue, Aug 31, 2004 at 11:11:02AM -0700, Ron St-Pierre wrote:
We have a web based application with data that is updated daily. The
biggest bottleneck occurs when we try to update
one of the tables. This table contains 58,000 rows and 62 columns, and
EVERY column
hi,
I have the following structure in my base 7.4.2
CREATE TABLE public.article (
art_id INTEGER NOT NULL,
rub_id INTEGER DEFAULT '0' NOT NULL,
art_titre VARCHAR(100) DEFAULT '' NOT NULL,
art_texte TEXT NOT NULL,
art_date DATE NOT NULL,
aut_id INTEGER,
CONSTRAINT article_pkey PRIMARY
thanks for the quick answer! My db driver is the native MS ADO, and
from
Delphi i use the AODExpress components which are wrapper classes to
reach
the ActiveX components from delhpi. The strange behaviour of that
query
is,
that all other queries executed in this environment are running fast,
Jean,
I have the following structure in my base 7.4.2
Upgrade to 7.4.5. The version you're using has several known issues with data
restore in the event of system failure.
Hash Join (cost=8.27..265637.59 rows=25 width=130)
Hash Cond: (outer.rub_id = inner.rub_id)
- Seq Scan on
On Tue, 31 Aug 2004 12:15:40 -0700, Josh Berkus [EMAIL PROTECTED] wrote:
Those look suspiciously like stock estimates. When was the last time you ran
ANALYZE?
the vacuum analyze ran just before the explain
--
Jean-Max Reymond
CKR Solutions
http://www.ckr-solutions.com
On 31 Aug 2004 at 20:59, Jean-Max Reymond wrote:
hi,
I want to optimize the following request and avoid the seq scan on the
table article (1000 rows).
explain SELECT art_id, art_titre, art_texte, rub_titre
FROM article inner join rubrique on article.rub_id = rubrique.rub_id
Ron St-Pierre wrote:
Yes, I know that it's not a very good idea, however queries are allowed
against all of those columns. One option is to disable some or all of the
indexes when we update, run the update, and recreate the indexes,
however it may slow down user queries. Because there are so
- Original Message -
From: Gary Doades [EMAIL PROTECTED]
Date: Tue, 31 Aug 2004 20:21:49 +0100
Subject: Re: [PERFORM] Optimizing a request
To: [EMAIL PROTECTED]
Have you run ANALYZE on this database after creating the indexes or loading the
data?
the indexes are created and the
On 31 Aug 2004 at 21:42, Jean-Max Reymond wrote:
- Original Message -
From: Gary Doades [EMAIL PROTECTED]
Date: Tue, 31 Aug 2004 20:21:49 +0100
Subject: Re: [PERFORM] Optimizing a request
To: [EMAIL PROTECTED]
Have you run ANALYZE on this database after creating the indexes
On Tue, 31 Aug 2004 21:16:46 +0100, Gary Doades [EMAIL PROTECTED] wrote:
I can only presume you mean 1 GB RAM. What exactly are your
settings for shared buffers and effective_cache_size?
for 1 GB RAM,
shared_buffers = 65536
effective_cache_size = 16384
Can you increase
On 31 Aug 2004 at 22:24, Jean-Max Reymond wrote:
On Tue, 31 Aug 2004 21:16:46 +0100, Gary Doades [EMAIL PROTECTED] wrote:
I can only presume you mean 1 GB RAM. What exactly are your
settings for shared buffers and effective_cache_size?
for 1 GB RAM,
shared_buffers = 65536
Hi,
Le Mardi 31 Août 2004 20:59, Jean-Max Reymond a écrit :
explain SELECT art_id, art_titre, art_texte, rub_titre
FROM article inner join rubrique on article.rub_id = rubrique.rub_id
where rub_parent = 8;
Hash Join (cost=8.27..265637.59 rows=25 width=130)
Hash Cond: (outer.rub_id =
Hello,
Is context switching problem resolved in 8.0?
Can I drop in another Xeon?
Thanks,
Jelle
On Wed, 2 Jun 2004, Josh Berkus wrote:
Folks,
I've been testing varying SPINS_PER_DELAY in a client's installation of
PostgreSQL against a copy of a production database, to test varying this
On Thu, Aug 26, 2004 at 12:04:48PM -0700, J. Andrew Rogers wrote:
The major caveat to having tables of this type is that you can only have
a primary key index. No other indexes are possible because the heap
constantly undergoes local reorganizations if you have a lot of write
traffic, the
Jellej,
Is context switching problem resolved in 8.0?
Can I drop in another Xeon?
Nope, not solved yet. However, it only affects certain data access patterns.
So don't use it as a reason not to go multi-processor.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
On Thu, Aug 26, 2004 at 11:39:42PM -0400, Greg Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Updated TODO item:
o Automatically maintain clustering on a table
This would require some background daemon to maintain clustering
during periods of low
Thanks for everyone's comments (Thomas, Steinar, Frank, Matt, William).
Right now I'm bench-marking the time it takes for each step
in the end of day update process and then I am going to test a few things:
- dropping most indexes, and check the full processing time and see if
there is any
Ron St-Pierre [EMAIL PROTECTED] writes:
Does anyone have some idea on how we can increase speed, either by
changing the updates, designing the database
differently, etc, etc? This is currently a big problem for us.
Other notables:
The UPDATE is run from a within a function: FOR rec
26 matches
Mail list logo
