pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: PFC <lists@boutiquenumerique.com>
To: Alex Turner <armtuk@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Partitioning / Clustering
Date: Sat, 14 May 2005 15:00:47 +0200
Message-ID: <op.sqrnrln1th1vuj@localhost> (raw)
In-Reply-To: <200505111013.52067.josh@agliodbs.com>
References: <5F94B6EB-3925-4CD3-A67F-4310890B438A@advfn.com>
	<200505111013.52067.josh@agliodbs.com>
	<1115798277.29223.233869472@webmail.messagingengine.com>
	<op.sqmuc2nnth1vuj@localhost>
	<33c6269f050512070842df1af3@mail.gmail.com>



> If you make the assertion that you are transferring equal or less
> session data between your session server (lets say an RDBMS) and the
> app server than you are between the app server and the client, an out
> of band 100Mb network for session information is plenty of bandwidth.

	So if you count on a mean page size of 6-8 kbytes gzipped, that will  
prevent you from caching the N first results of the Big Slow Search Query  
in a native object in the user session state (say, a list of integers  
indicating which rows match), so you will have to redo the Big Slow Search  
Query everytime the user clicks on Next Page instead of grabbing a set of  
cached row id's and doing a fast SELECT WHERE id IN ...
	This is the worst case ... I'd gzip() the row id's and stuff them in the  
session, that's always better than blowing up the database with the Big  
Slow Search Query everytime someone does Next Page...

> This also represents OLTP style traffic, which postgresql is pretty
> good at.  You should easily be able to get over 100Tps.  100 hits per
> second is an awful lot of traffic, more than any website I've managed
> will ever see.

	On the latest anandtech benchmarks, 100 hits per second on a blog/forum  
software is a big bi-opteron server running dotNET, at 99% load... it's a  
lot if you count only dynamic page hits.




view thread (49+ messages)

Message-ID: <op.sqrnrln1th1vuj@localhost>
Permalink:  ../op.sqrnrln1th1vuj@localhost/
Also on:    postgresql.org/message-id/op.sqrnrln1th1vuj@localhost

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: lists@boutiquenumerique.com, armtuk@gmail.com
  Subject: Re: Partitioning / Clustering
  In-Reply-To: <op.sqrnrln1th1vuj@localhost>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox