carl garland wrote:
>
> >perhaps why, even at 5 clients, the page views he shows never went
> >significantly above 10/sec?
>
> I think alot of it has to do with the web server/db setup not pg. They are
> using Apache/PHP and looking at their code every page has the additional
> overhead of making the db connection. Now if they had used AOLserver with
> its persistent db connecction pooling scheme they may have faired better ;)
PHP has a persistent PostgreSQL open pg_pConnect(....) and it does make
a difference.
I use postgres as a music database back-end for a PHP web server.
(Actually it is a web farm, with many instances of the database, one per
web server)
The one problem I have had with Postgres is its stubborn refusal to use
an index. I understand the reasons why it won't, but it is wrong, so I
sped it up by starting the backends with -fs.
That may be the issue.
On a side note:
I'm not sure of the current workings of the vacuum and statistics vs
indexing issue, I am new to this list, but I do have a 7.0.2 relevant
observation:
My music database has 50,000 arises and 210,000 albums. Many artists
have only one or 2 entries in the albums table (for the youngsters, CD
table ;-). About 34,000 have the integer key for "Various Artists" as
their artist entry, and another few thousand have things like "Movie
Soundtrack" and so on.
When the statistics are computed, these relatively few records with a
huge number of relations distort the statistics and make it impossible
to get postgres to use an index on that table without the -fs switch.
This is bad because it always forces use of an index, even when postgres
would legitimately ignore it.
--
http://www.mohawksoft.com
