"Y Sidhu" <[EMAIL PROTECTED]> writes:
> it may be table fragmentation. What kind of tables? We have 2 of them which
> experience lots of adds and deletes only. No updates. So a typical day
> experiences record adds a few dozen times on the order of 2.5 million. And
> deletes once daily. Each of the
Bill,
I suspect it is fragmentation of some sort. Vacuum times sometimes shoot up,
it may be table fragmentation. What kind of tables? We have 2 of them which
experience lots of adds and deletes only. No updates. So a typical day
experiences record adds a few dozen times on the order of 2.5 milli
In response to "Y Sidhu" <[EMAIL PROTECTED]>:
> My immediate problem is to decrease vacuum times.
Don't take this as being critical, I'm just trying to point out a slight
difference between what you're doing and what you think you're doing:
Your problem is not decreasing vacuum times. You _thin
My immediate problem is to decrease vacuum times.
Yudhvir
===
On 5/14/07, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
On Mon, May 14, 2007 at 12:02:03PM -0700, Y Sidhu wrote:
> I am sorry about this Jim, please understand that I am a newbie and am
> trying to solve long vacuum time problems an
On Mon, May 14, 2007 at 12:02:03PM -0700, Y Sidhu wrote:
> I am sorry about this Jim, please understand that I am a newbie and am
> trying to solve long vacuum time problems and get a handle on speeding up
> queries/reports. I was pointed to pg_stats and that's where I am at now. I
Well, I have no
I am sorry about this Jim, please understand that I am a newbie and am
trying to solve long vacuum time problems and get a handle on speeding up
queries/reports. I was pointed to pg_stats and that's where I am at now. I
have added this into my conf file:
stats_start_collector TRUE stats_reset_on
On Mon, May 14, 2007 at 11:09:21AM -0700, Y Sidhu wrote:
> The stats_block_level and stats_row_level are NOT enabled. The question is
> how to use pg_stats. Do I access/see them via the ANALYZE command? or using
> SQL. I cannot find any document which will get me started on this.
Ok, we're both co
The stats_block_level and stats_row_level are NOT enabled. The question is
how to use pg_stats. Do I access/see them via the ANALYZE command? or using
SQL. I cannot find any document which will get me started on this.
Yudhvir
--
On 5/14/07, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
P
Please include the list in your replies...
Ok, so you've got stats collection turned on. What's the question then?
And are stats_block_level and stats_row_level also enabled?
On Mon, May 14, 2007 at 09:28:46AM -0700, Y Sidhu wrote:
> yes
>
> Yudhvir
> ===
>
> On 5/14/07, Jim C. Nasby <[EMAIL PR
Daniel,
> basically we have a transactional web application. The users can browse
> through some entries in the database and start a bunch of heavy queries
> that take up to 15 minutes (if multiple such heavy queries run in
> parallel the performance of the database and webinterface drops very
>
Have you either re-loaded the config or restarted the server since
making those changes?
On Mon, May 14, 2007 at 09:16:54AM -0700, Y Sidhu wrote:
> I am trying to use them. I have set these values in my conf file:
> stats_start_collector TRUE stats_reset_on_server_start FALSE
> stats_command_str
I am trying to use them. I have set these values in my conf file:
stats_start_collector TRUE stats_reset_on_server_start FALSE
stats_command_string TRUE
now what?
Yudhvir
==
On 5/13/07, Shoaib Mir <[EMAIL PROTECTED]> wrote:
Can you be a little more specific? What exactly are you tryi
Tarhon-Onu Victor wrote:
Hi guys,
I'm looking for a database+hardware solution which should be able to
handle up to 500 requests per second.
Crucial questions:
1. Is this one client making 500 requests, or 500 clients making one
request per second?
2. Do you expect the indexes at
13 matches
Mail list logo
