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
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),
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.
*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
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
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.
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
Hmm ... what PG version is this, and what does VACUUM
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
