am 06.07.2006, um 9:40:16 +0300 mailte Eugeny N Dzhurinsky folgendes:
> In postgresql.conf I have these settings:
>
> shared_buffers = 4
> work_mem = 8192
> maintenance_work_mem = 16384
> max_stack_depth = 2048
>
> all other settings are left by default (except ones needed for pg_autovacuum
Hello!
I have a postgresql server serving thousands of tables. Sometime there are
queries which involves several tables.
In postgresql.conf I have these settings:
shared_buffers = 4
work_mem = 8192
maintenance_work_mem = 16384
max_stack_depth = 2048
all other settings are left by default (e
Kenji Morishige wrote:
I am currently running FreeBSD 4.11 (due to IT requirements for now) and
Adaptec's 2200S RAID controller running in RAID5. I was advised in the past
that the 2200S is actually a poor performing controller and obviously the
RAID5 is less than ideal for databases. I chose t
Eugeny N Dzhurinsky wrote:
On Wed, Jul 05, 2006 at 09:39:31AM -0400, Tom Lane wrote:
Eugeny N Dzhurinsky <[EMAIL PROTECTED]> writes:
but it seems pg_autovacuum does not do vacuuming on system tables.
There was a bug awhile back whereby autovac failed to notice temp table
cleanup at connection
I am currently running FreeBSD 4.11 (due to IT requirements for now) and
Adaptec's 2200S RAID controller running in RAID5. I was advised in the past
that the 2200S is actually a poor performing controller and obviously the
RAID5 is less than ideal for databases. I chose to run the controller in
R
andy rost wrote:
effective_cache_size = 27462# typically 8KB each
This seems like it might be a little low... How much memory do you have
in the system? Then again, with your shared_mem set so high, perhaps
it's not that bad, but it might make sense to swap those two settings
Hi, Gregory,
Gregory S. Williamson wrote:
> A sodden late night idea ... schemas don't need to have names that
> are meaningful to outsiders.
Yes, but having schema names like A34FZ37 not only qualifies for
thedailywtf.com, but also tends to produce maintainance nightmares.
And it still allows t
Hi Stephen,
Thanks for your input. My follow ups are interleaved below ...
Stephen Frost wrote:
* andy rost ([EMAIL PROTECTED]) wrote:
We're in the process of porting from Informix 9.4 to PostgreSQL 8.1.3.
Our PostgreSQL server is an AMD Opteron Dual Core 275 with two 2.2 Ghz
64-bit process
On Jul 5, 2006, at 10:43 AM, andy rost wrote:
We're in the process of porting from Informix 9.4 to PostgreSQL
8.1.3. Our PostgreSQL server is an AMD Opteron Dual Core 275 with
two 2.2 Ghz 64-bit processors. There are two internal drives and an
external enclosure containing 14 drives (confi
On Wed, Jul 05, 2006 at 09:39:31AM -0400, Tom Lane wrote:
> Eugeny N Dzhurinsky <[EMAIL PROTECTED]> writes:
> > but it seems pg_autovacuum does not do vacuuming on system tables.
>
> There was a bug awhile back whereby autovac failed to notice temp table
> cleanup at connection end --- maybe you n
* andy rost ([EMAIL PROTECTED]) wrote:
> We're in the process of porting from Informix 9.4 to PostgreSQL 8.1.3.
> Our PostgreSQL server is an AMD Opteron Dual Core 275 with two 2.2 Ghz
> 64-bit processors. There are two internal drives and an external
> enclosure containing 14 drives (configured
We're in the process of porting from Informix 9.4 to PostgreSQL 8.1.3.
Our PostgreSQL server is an AMD Opteron Dual Core 275 with two 2.2 Ghz
64-bit processors. There are two internal drives and an external
enclosure containing 14 drives (configured as 7 pairs of mirrored drives
- four pairs fo
Eugeny N Dzhurinsky <[EMAIL PROTECTED]> writes:
> but it seems pg_autovacuum does not do vacuuming on system tables.
There was a bug awhile back whereby autovac failed to notice temp table
cleanup at connection end --- maybe you need to update?
regards, tom lane
-
Hello!
I facing some strange problems with PostgreSQL 8.0 performance.
I have application which handles a lot of tasks, each task is keps in separate
table. Those tables are dropped and created again periodically (precisely -
when new task results came back from remote server). Also each table can
A sodden late night idea ... schemas don't need to have names that are
meaningful to outsiders.
Still, the point about "political" aspects is an important one. OTH, schemas
provide an elegant way of segregating data.
My $0.02 (not worth what it was)
Greg Williamson
DBA
GlobeXplorer LLC
-O
Hi, Mikael,
Just my 2 cents:
Mikael Carneholm wrote:
> Do you really need to create one *DB* per client - that is, is one
> schema (in the same DB) per client out of the question?
Sometimes, schemas would work _technically_, but not politically, as a
postgresql user cannot be prevented from list
16 matches
Mail list logo
