[PERFORM] performance with column orders

2004-08-08 Thread Jim Thomason
I couldn't track down recent info in the archives, so I figured I'd ask here. Does the order of columns still have an impact on table speed? Back in the olden days, it used to be that fixed width columns (integer, tinyint, etc.) should be the first ("left") columns in the table and variable width

Re: [PERFORM] Performance Bottleneck

2004-08-08 Thread Tatsuo Ishii
> Arjen van der Meijden wrote: > > > On 8-8-2004 16:29, Matt Clark wrote: > > > >> There are two well-worn and very mature techniques for dealing with the > >> issue of web apps using one DB connection per apache process, both of > >> which > >> work extremely well and attack the issue at its so

Re: [PERFORM] Performance Bottleneck

2004-08-08 Thread Tatsuo Ishii
> Jeff wrote: > > > > On Aug 8, 2004, at 1:29 AM, Martin Foster wrote: > > > >> I am currently making use of Apache::DBI which overrides the > >> DBI::disconnect call and keeps a pool of active connections for use > >> when need be. Since it offloads the pooling to the webserver, it > >> see

Re: [PERFORM] Performance Bottleneck

2004-08-08 Thread Martin Foster
Arjen van der Meijden wrote: On 8-8-2004 16:29, Matt Clark wrote: There are two well-worn and very mature techniques for dealing with the issue of web apps using one DB connection per apache process, both of which work extremely well and attack the issue at its source. 1)Use a front-end cachi

Re: [PERFORM] Performance Bottleneck

2004-08-08 Thread Arjen van der Meijden
On 8-8-2004 16:29, Matt Clark wrote: There are two well-worn and very mature techniques for dealing with the issue of web apps using one DB connection per apache process, both of which work extremely well and attack the issue at its source. 1) Use a front-end caching proxy like Squid as an acc

Re: [PERFORM] Performance Bottleneck

2004-08-08 Thread Martin Foster
Jeff wrote: On Aug 8, 2004, at 1:29 AM, Martin Foster wrote: I am currently making use of Apache::DBI which overrides the DBI::disconnect call and keeps a pool of active connections for use when need be. Since it offloads the pooling to the webserver, it seems more advantageous then pgpool whi

Re: [PERFORM] Performance Bottleneck

2004-08-08 Thread Matt Clark
> And this is exactly where the pgpool advantage lies. > Especially with the > TPC-W, the Apache is serving a mix of PHP (or whatever CGI > technique is > used) and static content like images. Since the 200+ Apache > kids serve > any of that content by random and the emulated browsers very mu

Re: [PERFORM] Performance Bottleneck

2004-08-08 Thread Jan Wieck
On 8/8/2004 8:10 AM, Jeff wrote: On Aug 8, 2004, at 1:29 AM, Martin Foster wrote: I am currently making use of Apache::DBI which overrides the DBI::disconnect call and keeps a pool of active connections for use when need be. Since it offloads the pooling to the webserver, it seems more advanta

Re: [PERFORM] Performance Bottleneck

2004-08-08 Thread Jeff
On Aug 8, 2004, at 1:29 AM, Martin Foster wrote: I am currently making use of Apache::DBI which overrides the DBI::disconnect call and keeps a pool of active connections for use when need be. Since it offloads the pooling to the webserver, it seems more advantageous then pgpool which while bei

Re: [PERFORM] Performance Bottleneck

2004-08-08 Thread Mike Benoit
On Fri, 2004-08-06 at 23:18 +, Martin Foster wrote: > Mike Benoit wrote: > > > On Wed, 2004-08-04 at 17:25 +0200, Gaetano Mendola wrote: > > > > > >>>The queries themselves are simple, normally drawing information from one > >>>table with few conditions or in the most complex cases using jo