Shridhar Daithankar wrote:
On 10 Jul 2003 at 0:43, Martin Foster wrote:
As for creating a new table, that in itself is a nice idea. But it
would cause issues for people currently in the realm. Their posts
would essentially dissapear from site and cause more confusion then its
worth.
No t
On 10 Jul 2003 at 0:43, Martin Foster wrote:
> As for creating a new table, that in itself is a nice idea. But it
> would cause issues for people currently in the realm. Their posts
> would essentially dissapear from site and cause more confusion then its
> worth.
No they won't. Say you hav
Shridhar Daithankar wrote:
I have an idea.
How about creating a table for each day. Use it for a while and rename it.
Since you can rename a table in transaction, it should not be a problem.
You can use inheritance if you want to query all of them. Using indexes and
foregin keys on inherited
Dennis Björklund wrote:
On Sun, 6 Jul 2003, Martin Foster wrote:
The processor seems to be purposely sitting there twiddling it's thumbs.
Which leads me to believe that perhaps the nice levels have to be
changed on the server itself?
It could also be all the usual things that affect perform
On Mon, 7 Jul 2003, Matthew Nuzum wrote:
> > A common problem is a table like this:
> >
> > create table test (info text, id int8 primary key);
> > insert into test values ('ted',1);
> > .. a few thousand more inserts;
> > vacuum full;
> > analyze;
> > select * from test where id=1;
> >
> > will
> A common problem is a table like this:
>
> create table test (info text, id int8 primary key);
> insert into test values ('ted',1);
> .. a few thousand more inserts;
> vacuum full;
> analyze;
> select * from test where id=1;
>
> will result in a seq scan, always, because the 1 by itself is
> au
scott.marlowe wrote:
I would try a few things. First off, effective_cache_size is the size
measured in 8k blocks, so 512 would be a setting of 4 Megs. Probably a
little low. If you average 512Meg free, that would be a setting of 65536.
Note that the higer the effective_cache_size, the more
On Sun, 6 Jul 2003, Martin Foster wrote:
> Shridhar Daithankar wrote:
> >
> > It gives hint to psotgresql how much file system cache is available in the
> > system.
> >
> > You have 1GB memory and your application requirement does not exceed 400MB. So
> > OS can use roughly 600MB for file sys
On Sun, 6 Jul 2003, Martin Foster wrote:
> The processor seems to be purposely sitting there twiddling it's thumbs.
> Which leads me to believe that perhaps the nice levels have to be
> changed on the server itself?
It could also be all the usual things that affect performance. Are your
quer
Richard Huxton wrote:
I don't know the *BSDs myself, but do you have the equivalent of iostat/vmstat
output you could get for us? Also a snapshot of "top" output? People are
going to want to see:
- overall memory usage (free/buffers/cache/swap)
- memory usage per process
- disk activity (block
Tom Lane wrote:
Martin Foster <[EMAIL PROTECTED]> writes:
The only time that I have ever seen load averages of 30 or more under
OpenBSD is when one of my scripts goes wild.
Note also that "high load average" is not per se an indication that
anything is wrong. In Postgres, if you have thirty qu
Shridhar Daithankar wrote:
It gives hint to psotgresql how much file system cache is available in the
system.
You have 1GB memory and your application requirement does not exceed 400MB. So
OS can use roughly 600MB for file system cache. In that case you can set this
parameter to 400MB cache to
Martin Foster <[EMAIL PROTECTED]> writes:
>> The only time that I have ever seen load averages of 30 or more under
>> OpenBSD is when one of my scripts goes wild.
Note also that "high load average" is not per se an indication that
anything is wrong. In Postgres, if you have thirty queries waiting
On Sunday 06 July 2003 15:56, Martin Foster wrote:
> effective_cache_size seems interesting, though the description is
> somewhat lacking. Is this related to the swap partition and how much of
> it will be used by PostgreSQL? If I am correct, this should be fairly
> low? Martin Foster
It gives
Richard Huxton wrote:
On Sunday 06 Jul 2003 5:54 am, Martin Foster wrote:
The only time that I have ever seen load averages of 30 or more under
OpenBSD is when one of my scripts goes wild.However, I can say that
I am also seeing these load averages under PostgreSQL 7.3.2 after a
migration to
Shridhar Daithankar wrote:
On 5 Jul 2003 at 22:54, Martin Foster wrote:
What I would like to know is. Why? The kernel has been compiled to
handle the number of concurrent connections, the server may not be the
best, but it should be able to handle the requests: PIII 1Ghz, 1GB
SDRAM, 2 IDE
On 5 Jul 2003 at 22:54, Martin Foster wrote:
> What I would like to know is. Why? The kernel has been compiled to
> handle the number of concurrent connections, the server may not be the
> best, but it should be able to handle the requests: PIII 1Ghz, 1GB
> SDRAM, 2 IDE 20GB drives.
>
> I h
On Sunday 06 Jul 2003 5:54 am, Martin Foster wrote:
> The only time that I have ever seen load averages of 30 or more under
> OpenBSD is when one of my scripts goes wild.However, I can say that
> I am also seeing these load averages under PostgreSQL 7.3.2 after a
> migration to it from MySQL.
[
The only time that I have ever seen load averages of 30 or more under
OpenBSD is when one of my scripts goes wild.However, I can say that
I am also seeing these load averages under PostgreSQL 7.3.2 after a
migration to it from MySQL.
MySQL Statistics:
Uptime: 1055352 Threads: 178 Question
19 matches
Mail list logo
