On Sat, May 26, 2007 at 10:52:14AM -0400, [EMAIL PROTECTED] wrote:
Do you want to be the one person who does notice a problem? :-)
Right, and notice that when you notice the problem _may not_ be when
it happens. The problem with errors in memory (or on disk
controllers, another place not to
On Tue, May 22, 2007 at 09:29:00AM +0200, PFC wrote:
This does not run a complete sort on the table. It would be about as
fast as your seq scan disk throughput. Obviously, the end result is
not as
good as a real CLUSTER since the table will be made up of several ordered
On Tue, May 22, 2007 at 12:56:21PM -0400, Chander Ganesan wrote:
Are there any performance improvements that come from using a domain
over a check constraint (aside from the ease of management component)?
No. Plus support for domain constraints isn't universal (plpgsql doesn't
honor them, for
On Wed, May 23, 2007 at 11:58:06AM -0700, Y Sidhu wrote:
Is there any easy way to take a database and add/delete records to create
fragmentation of the records and indexes. I am trying to recreate high
vacuum times.
Update random rows, then do a vacuum. That will result in free space in
random
What does top report as using the most memory?
On Wed, May 23, 2007 at 11:01:24PM -0300, Leandro Guimar?es dos Santos wrote:
Hi all,
I have a 4 CPU, 4GB Ram memory box running PostgreSql 8.2.3 under Win 2003 in
a very high IO intensive insert application.
The application
On Fri, May 25, 2007 at 10:29:30AM +0200, Bastian Voigt wrote:
Hi *,
for caching large autogenerated XML files, I have created a bytea table
in my database so that the cached files can be used by multiple servers.
There are about 500 rows and 10-20 Updates per minute on the table. The
Jim C. Nasby wrote:
On Tue, May 22, 2007 at 12:56:21PM -0400, Chander Ganesan wrote:
Are there any performance improvements that come from using a domain
over a check constraint (aside from the ease of management component)?
No. Plus support for domain constraints isn't universal (plpgsql
On Sun, 27 May 2007 17:53:38 +0200, Jim C. Nasby [EMAIL PROTECTED]
wrote:
On Tue, May 22, 2007 at 09:29:00AM +0200, PFC wrote:
This does not run a complete sort on the table. It would be about as
fast as your seq scan disk throughput. Obviously, the end result is
not as
good as
On 5/27/07, PFC [EMAIL PROTECTED] wrote:
PostgreSQL humiliates InnoDB on CPU-bound workloads (about 2x faster
since I run it on dual core ; InnoDB uses only one core). However, InnoDB
can automatically cluster tables without maintenance.
How does it know what to cluster by? Does it
How does it know what to cluster by? Does it gather statistics about
query patterns on which it can decide an optimal clustering, or does
it merely follow a clustering previously set up by the user?
Nothing fancy, InnoDB ALWAYS clusters on the primary key, whatever it is.
So, if you can
I am re-running it with other tuning, notably cost-based vacuum
delay and less frequent checkpoints, and it is a *lot* smoother.
These take a full night to run, so I'll post more results when I
have usefull stuff to show.
This has proven to be a very interesting trip to
11 matches
Mail list logo
