ok. if i don't misunderstand you (english is not my mother tongue, so i can
be wrong). your point is that speed is not necesarily performance, that's
right.
so, the real question is what is the best filesystem for optimal speed in
postgresql?
___
Fabio,
> The Vacuum's don't take too long, 10 minutes at most. I can tell from ps
> -ef | grep and top that its the selects/inserts/updates from the postgres
> related to our app that take all that time up. If we rerun initdb and
> reload the data, it works great for about two days, then goes ba
The Vacuum's don't take too long, 10 minutes at most. I can tell from ps
-ef | grep and top that its the selects/inserts/updates from the postgres
related to our app that take all that time up. If we rerun initdb and
reload the data, it works great for about two days, then goes bad again.
We a
Fabio,
> We run VACUUM ANALYZE after we remove about 1000 rows every hour on the
> halh hour. Our max_fsm_pages is set to 1
Have you checked how long these vacuums take? If they are starting to
overlap, that would explain your high CPU usage and poor performance.You
might want to con
Andrew,
> Its a way of representing a tree with right-left pointers in each
> record (basically re-inventing a hierarchical database
> in a relational model...). A good description is in Joe Celko's SQL
> For Smarties book. Selection is very fast because
> any node's children have node ID's b
thanx a lot
_
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, pl
On Mon, Mar 29, 2004 at 12:00:16 -0500,
Fabio Esposito <[EMAIL PROTECTED]> wrote:
>
> I'm sorry all, when you say regular user as opposed to superuser are you
> talking about the user that postgres is installed and running as? Should
> this be done as the os's root?
The os user used for creati
Its a way of representing a tree with right-left pointers in each
record (basically re-inventing a hierarchical database
in a relational model...). A good description is in Joe Celko's SQL
For Smarties book. Selection is very fast because
any node's children have node ID's between the right an
On Mar 29, 2004, at 9:36 AM, Tom Lane wrote:
"Marcus Andree S. Magalhaes" <[EMAIL PROTECTED]> writes:
Also do you run VACUUM ANALYZE as a superuser, or as a regular user?
As a regular user (database owner). Is thery any difference when
vacuuming
as a super user?
That's your problem. A regular u
I'm sorry all, when you say regular user as opposed to superuser are you
talking about the user that postgres is installed and running as? Should
this be done as the os's root?
Fabio
On Mon, 29 Mar 2004, Tom Lane wrote:
> "Marcus Andree S. Magalhaes" <[EMAIL PROTECTED]> writes:
> >> Also do yo
Andrew,
> I used to use the connect-by patch, but have since rewritten everything
> to use a nested set model.
Cool! You're probably the only person I know other than me using nested
sets
in a production environment.
can you explain me what is a nested set?
"Marcus Andree S. Magalhaes" <[EMAIL PROTECTED]> writes:
>> Also do you run VACUUM ANALYZE as a superuser, or as a regular user?
> As a regular user (database owner). Is thery any difference when vacuuming
> as a super user?
That's your problem. A regular user won't have permissions to vacuum
an
On Fri, 26 Mar 2004, Josh Berkus wrote:
> Fabio,
>
> > Recently it started eating up the cpu, and cannot keepup with the system
> > like it used to. The interesting thing here is that it still runs great
> > on an older system with less ram, one slower cpu, and an older disk.
>
> This really p
> Marcus,
>
>> We are experiencing exactly the same problem here, and we use 7.4 on
>> Linux/i386 SMP (2 processors). Our databases does even more access:
>> about 30k selects per hour, 10k updates and inserts per hour
>>
>> Vacuum analyze is done daily.
>
> What is your max_fsm_pages setting?
14 matches
Mail list logo
