Today is the first official day of this weeks and the system run better in
serveral points but there are still some points that need to be corrected. Some
queries or some tables are very slow. I think the queries inside the programe
need to be rewrite.
Now I put the sort mem to a little bit bigger:
On Tue, 4 Jan 2005 [EMAIL PROTECTED] wrote:
> Today is the first official day of this weeks and the system run better in
> serveral points but there are still some points that need to be corrected.
> Some
> queries or some tables are very slow. I think the queries inside the programe
> need to be
Dave Cramer wrote:
Well, it's not quite that simple
the rule of thumb is 6-10% of available memory before postgres loads
is allocated to shared_buffers.
then effective cache is set to the SUM of shared_buffers + kernel buffers
Then you have to look at individual slow queries to determine why they
Yann,
> are there any plans for rewriting queries to preexisting materialized
> views? I mean, rewrite a query (within the optimizer) to use a
> materialized view instead of the originating table?
Automatically, and by default, no. Using the RULES system? Yes, you can
already do this and the
All,
I am currently working on a project for my company that entails
Databasing upwards of 300 million specific parameters. In the current
DB Design, these parameters are mapped against two lookup tables (2
million, and 1.5 million respectively) and I am having extreme issues
getting PG to scal
> 1)the 250 million records are currently whipped and reinserted as a
> "daily snapshot" and the fastest way I have found "COPY" to do this from
> a file is no where near fast enough to do this. SQL*Loader from Oracle
> does some things that I need, ie Direct Path to the db files access
> (skipp
Wagner,
>If there is anyone that can give me some tweak parameters or design
> help on this, it would be ridiculously appreciated. I have already
> created this in Oracle and it works, but we don't want to have to pay
> the monster if something as wonderful as Postgres can handle it.
In addi
Rod,
I do this, PG gets forked many times, it is tough to find the max
number of times I can do this, but I have a Proc::Queue Manager Perl
driver that handles all of the copy calls. I have a quad CPU machine.
Each COPY only hits ones CPU for like 2.1% but anything over about 5
kicks the load av
On Tue, 2005-01-04 at 13:26 -0600, Wager, Ryan D [NTK] wrote:
> Rod,
> I do this, PG gets forked many times, it is tough to find the max
> number of times I can do this, but I have a Proc::Queue Manager Perl
> driver that handles all of the copy calls. I have a quad CPU machine.
> Each COPY only
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Pallav Kalva)
wrote:
>> Then you have to look at individual slow queries to determine why
>> they are slow, fortunately you are running 7.4 so you can set
>> log_min_duration to some number like 1000ms and then
>> try to analyze why tho
Ryan,
> > I do this, PG gets forked many times, it is tough to find the max
> > number of times I can do this, but I have a Proc::Queue Manager Perl
> > driver that handles all of the copy calls. I have a quad CPU machine.
> > Each COPY only hits ones CPU for like 2.1% but anything over about 5
On Tue, 2005-01-04 at 14:02 -0500, Rod Taylor wrote:
> > 1)the 250 million records are currently whipped and reinserted as a
> > "daily snapshot" and the fastest way I have found "COPY" to do this from
> > a file is no where near fast enough to do this. SQL*Loader from Oracle
> > does some thing
> > I will put more ram but someone said RH 9.0 had poor recognition on the Ram
> > above 4 Gb?
>
> I think they were refering to 32 bit architectures, not distributions as
> such.
Sorry for wrong reason , then should I increase more RAM than 4 Gb. on 32 bit
Arche.?
> > Should I close the hyperth
13 matches
Mail list logo