Re: [PERFORM] Database Statistics???

smiley2211 wrote: > > Thanks Tom and Scott...that worked for a NEW database but not on the original > SLOW database...meaning - I backed up the SLOW database and restored it to a > NEW database and the query ran EXTREMELY FAST :clap: Have you ever vacuumed the DB? -- Alvaro Herrera

Re: [PERFORM] TRUNCATE TABLE

Tom Lane wrote: Adriaan van Os <[EMAIL PROTECTED]> writes: I started another test. I copied an existing database (not very large, 35 tables, typically a few hundred up to a few thousand records) with CREATE DATABASE testdb TEMPLATE mydb and started to remove random tables from testdb with DROP T

Re: [PERFORM] TRUNCATE TABLE

Hello, I tested speed difference between TRUNCATE TABLE and DROP TABLE (tested on my notebook ext3 and Linux fedora 7): CREATE OR REPLACE FUNCTION test01() RETURNS SETOF double precision AS $$ DECLARE t1 timestamp with time zone; BEGIN CREATE TEMP TABLE foo(a integer); FOR i IN 1..1000 LOOP

Re: [PERFORM] Database Statistics???

Am Freitag 13 Juli 2007 schrieb smiley2211: > Hello all, > > I am a bit confused...I have a database which was performing very POORLY > selecting from a view (posted earlier) on one server but extremely fast on > another server... > > I just backed up the database from the FAST server and loaded to

Re: [PERFORM] Database Statistics???

Thanks Tom and Scott...that worked for a NEW database but not on the original SLOW database...meaning - I backed up the SLOW database and restored it to a NEW database and the query ran EXTREMELY FAST :clap: Scott - (your question - What was the size of the slow databases data store compared to t

Re: [PERFORM] Database Statistics???

On 2007-07-13 smiley2211 wrote: > I am a bit confused...I have a database which was performing very > POORLY selecting from a view (posted earlier) on one server but > extremely fast on another server... EXPLAIN ANALYZE'ing the query will show you the planner's estimates. The query plans should gi

Re: [PERFORM] Database Statistics???

smiley2211 wrote: Hello all, I am a bit confused...I have a database which was performing very POORLY selecting from a view (posted earlier) on one server but extremely fast on another server... I just backed up the database from the FAST server and loaded to the SLOW server and it ran just as

Re: [PERFORM] TRUNCATE TABLE

Tom Lane wrote: > Adriaan van Os <[EMAIL PROTECTED]> writes: > > I started another test. I copied an existing database (not very large, > > 35 tables, typically a few hundred up to a few thousand records) with > > CREATE DATABASE testdb TEMPLATE mydb and started to remove random > > tables from tes

Re: [PERFORM] TRUNCATE TABLE

On Fri, Jul 13, 2007 at 12:30:46PM -0400, Tom Lane wrote: > Adriaan van Os <[EMAIL PROTECTED]> writes: > > I started another test. I copied an existing database (not very large, > > 35 tables, typically a few hundred up to a few thousand records) with > > CREATE DATABASE testdb TEMPLATE mydb and st

[PERFORM] Database Statistics???

Hello all, I am a bit confused...I have a database which was performing very POORLY selecting from a view (posted earlier) on one server but extremely fast on another server... I just backed up the database from the FAST server and loaded to the SLOW server and it ran just as fast as it original

Re: [PERFORM] TRUNCATE TABLE

Adriaan van Os <[EMAIL PROTECTED]> writes: > I started another test. I copied an existing database (not very large, > 35 tables, typically a few hundred up to a few thousand records) with > CREATE DATABASE testdb TEMPLATE mydb and started to remove random > tables from testdb with DROP TABLE and TR

Re: [PERFORM] TRUNCATE TABLE

On Fri, Jul 13, 2007 at 06:17:18PM +0200, Adriaan van Os wrote: > The hardware is an Intel dual-core 17-inch MacBook Pro running Mac > OS X 10.4. To isolate things, have you tried testing a different operating system? /* Steinar */ -- Homepage: http://www.sesse.net/ ---

Re: [PERFORM] TRUNCATE TABLE

Tom Lane wrote: Michael Stone <[EMAIL PROTECTED]> writes: xfs' slowness is proportional to the *number* rather than the *size* of the files. In postgres you'll tend to have fewer, larger, files than you would in (e.g.) a source code repository, so it is generally more important to have a files

Re: [PERFORM] TRUNCATE TABLE

Michael Stone <[EMAIL PROTECTED]> writes: > xfs' slowness is proportional to the *number* rather than the *size* of > the files. In postgres you'll tend to have fewer, larger, files than you > would in (e.g.) a source code repository, so it is generally more > important to have a filesystem that

Re: [PERFORM] TRUNCATE TABLE

On Fri, Jul 13, 2007 at 09:47:06AM +0200, Adriaan van Os wrote: That's a remarkable advice, because XFS is known to be slow at creating and deleting files, see and . xfs' slowness is proportional to the *number

Re: [PERFORM] PostgreSQL publishes first real benchmark

I had such great hopes for this thread. "Alas, poor Yorick! I knew him, Horatio ..." On Thu, Jul 12, 2007 at 11:00:54AM -0400, Greg Smith wrote: > On Thu, 12 Jul 2007, Gregory Stark wrote: > > >In any case I wouldn't think the use case for a feature like this would > >actually apply in the

Re: [PERFORM] PostgreSQL publishes first real benchmark

Le mercredi 11 juillet 2007 à 13:37 -0300, André Gomes Lamas Otero a écrit : > I don't this so, because DB2 is running on a Sun Sparc T1 processor > (http://www.sun.com/processors/UltraSPARC-T1/) that's implements much > more features, like thread level parelelism, than AMD Opteron. > > the DB2

Re: [PERFORM] TRUNCATE TABLE

On 7/13/07, Jean-Max Reymond <[EMAIL PROTECTED]> wrote: Adriaan van Os a écrit : > That's a remarkable advice, because XFS is known to be slow at creating > and deleting files, see and > . > date of article: Fri

Re: [PERFORM] TRUNCATE TABLE

Adriaan van Os a écrit : That's a remarkable advice, because XFS is known to be slow at creating and deleting files, see and . date of article: Fri Jul 25 2003 ! ---(end of broadcast

Re: [PERFORM] TRUNCATE TABLE

"Adriaan van Os" <[EMAIL PROTECTED]> writes: > That's a remarkable advice, because XFS is known to be slow at creating and > deleting files, see and > . I think this is a case of "you're both right". XFS may have

Re: [PERFORM] TRUNCATE TABLE

Gregory Stark wrote: What filesystem is this? Ext3 on Fedora Linux. Some filesystems are notoriously slow at deleting large files. The mythtv folk who face this problem regularly recommend either JFS or XFS for this purpose. That's a remarkable advice, because XFS is known to be slow at cre