Hi ,
I am sorry that my question is out of line with
this group(performance) but I need
an urgent help L …pls .. I need
to know how to change the length of the column.
Thanks and hoping that u will not ignore my question
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
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 notice
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 p
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 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, th
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 t
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
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
> e
On Tue, 31 Aug 2004 16:13:58 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
> That seems like a very strange plan choice given those estimated row
> counts. I'd have expected it to use a nestloop with inner index scan
> on article_rub_id_index. You haven't done anything odd like disable
> nestloop,
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 default_statis
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 t
Jean-Max Reymond <[EMAIL PROTECTED]> writes:
> 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 = "inner".rub_id
- 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 th
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 many
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
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
--
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
> 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 fa
> >That looks like poor database normalization, really. Are you
> sure you
> >don't want to split this into multiple tables instead of having 62
> >columns?
> >
> No, it is properly normalized. The data in this table is stock
> fundamentals, stuff like 52 week high, ex-dividend date, etc, etc.
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_pk
On Tue, Aug 31, 2004 at 11:35:38AM -0700, Ron St-Pierre wrote:
> We're doing it in multiple transactions within the function. Could we do
> something like this?:
>
>
> BEGIN
> FOR rec IN SELECT field01, field02, ... FROM otherTable LOOP
> RETURN NEXT rec;
> UPDATE dataTable SET field01=r
On Tue, 31 Aug 2004 11:11:02 -0700
Ron St-Pierre <[EMAIL PROTECTED]> wrote:
>Postgres 7.4.3
>debian stable
>2 GB RAM
>80 DB IDE drive (we can't change it)
>
>shared_buffers = 2048
>sort_mem = 1024
>max_fsm_pages = 4
>checkpoint_segments = 5
>random_page
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 is
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
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 usua
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 is
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
relu
> 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 co
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 converts/
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?
> 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
32 matches
Mail list logo
