Re: [HACKERS] [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL

2006-06-22 Thread David Roussel
Arjen van der Meijden wrote: Here is a graph of our performance measured on PostgreSQL: http://achelois.tweakers.net/~acm/pgsql-t2000/T2000-schaling-postgresql.png ... The "perfect" line is based on the "Max" value for 1 core and then just multiplied by the amount of cores to have

Re: [PERFORM] 2 phase commit: performance implications?

2005-12-20 Thread David Roussel
The only issue is to ensure that a query near a boundary between two adjacent areas behaves as though there was no partitioning. To do this, I'm looking into using 8.1's new 2PC to allow me to selectively copy data inserted near a boundary into the adjacent neighbouring databases, so that

Re: [PERFORM] filesystem performance with lots of files

2005-12-20 Thread David Roussel
David Lang wrote:   ext3 has an option to make searching directories faster (htree), but enabling it kills performance when you create files. And this doesn't help with large files. The ReiserFS white paper talks about the data structure he uses to store directories (some kind of tree),

Re: [PERFORM] Best way to check for new data.

2005-10-31 Thread David Roussel
Rodrigo Madera wrote: I have a table that holds entries as in a ficticious table Log(id integer, msg text).   Lets say then that I have the program log_tail that has as it´s sole purpose to print newly added data elements.   What is the best solution in terms of performace? I hav

Re: [PERFORM] Partitioning / Clustering

2005-05-11 Thread David Roussel
For an interesting look at scalability, clustering, caching, etc for a large site have a look at how livejournal did it. http://www.danga.com/words/2004_lisa/lisa04.pdf They have 2.6 Million active users, posting 200 new blog entries per minute, plus many comments and countless page views. Althou

Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL 8.0)

2005-05-09 Thread David Roussel
*Note: * Testing has shown PostgreSQL's hash indexes to perform no better than B-tree indexes, and the index size and build time for hash indexes is much worse. For these reasons, hash index use is presently discouraged. May I know for simple "=" operation query, for "Hash index" vs. "B-tree"

Re: [PERFORM] Table stats

2005-05-05 Thread David Roussel
> Should there not be at least one Index Scan showing in the stats? not if there was a table scan ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PERFORM] COPY vs INSERT

2005-05-04 Thread David Roussel
> COPY invokes all the same logic as INSERT on the server side > (rowexclusive locking, transaction log, updating indexes, rules). > The difference is that all the rows are inserted as a single > transaction. This reduces the number of fsync's on the xlog, > which may be a limiting factor for you.

Re: [PERFORM] Index bloat problem?

2005-04-22 Thread David Roussel
On Fri, 22 Apr 2005 10:06:33 -0400, "Tom Lane" <[EMAIL PROTECTED]> said: > David Roussel <[EMAIL PROTECTED]> writes: > > |dave_data_update_eventsr 1593600.0 40209 > > |dave_data_update_events_event_id_key i 1912320.0 29271 >

Re: [PERFORM] Index bloat problem?

2005-04-22 Thread David Roussel
On 22 Apr 2005, at 06:57, Tom Lane wrote: Bill Chandler <[EMAIL PROTECTED]> writes: Client is reporting that the size of an index is greater than the number of rows in the table (1.9 million vs. 1.5 million). This thread seems to have wandered away without asking the critical question "what did you

[PERFORM] How can an index be larger than a table

2005-04-21 Thread David Roussel
Hi, I have a series of tables with identical structure. Some contain a few thousand rows and some contain 3,000,000 rows. Another applicate writes the rows and my applicate reads then just by selecting where pk > last_seen_pk limit 2000. I've found that one of the tables, when selecting from it