Thread: Weird processes
I have been having some problems with my database/web server machine and ma having difficulty in finding out what the problem is. I have two machines configured exactly the same; one for development and one for production. Pages on production are taking up to 10X longer to load than the same pages on development. We have tested the line speeds and they are comparable. I have been searching through the processes and have come across some items that I have never seen on the machine before. The processes listed below seem to be hanging around much longer than they should be. Perl is the cgi and the only postgres user on this machine is the web server. Any help would be greatly appreciated. Below is the output: postgres 7633 2.6 2.2 505612 45968 ? S 10:57 0:02 postgres: postgres pro [local] SELECT nobody 7679 1.7 0.7 16792 15616 ? S 10:57 0:01 perl /www/cgi-bin/reporting/report_search.pl nobody 7682 1.5 0.3 8712 7548 ? S 10:57 0:01 perl /www/cgi-bin/staffing/orderconfirmation.pl postgres 7684 2.5 1.5 505100 32864 ? S 10:57 0:02 postgres: postgres pro [local] SELECT postgres 7685 1.4 1.6 505008 34508 ? S 10:57 0:01 postgres: postgres pro [local] idle postgres 7758 3.9 2.2 505088 45864 ? S 10:58 0:02 postgres: postgres pro [local] SELECT nobody 7768 0.7 0.3 8832 7672 ? S 10:58 0:00 perl /www/cgi-bin/userapp/csc/contractor/contractorsearch.pl postgres 7769 2.2 1.5 505096 32864 ? S 10:58 0:01 postgres: postgres pro [local] SELECT nobody 7800 0.0 0.1 5384 2596 ? S 10:58 0:00 /www/bin/httpd -DSSL nobody 7842 0.3 0.3 8768 7600 ? S 10:58 0:00 perl /www/cgi-bin/passthru.pl nobody 7846 0.4 0.3 8768 7600 ? S 10:58 0:00 perl /www/cgi-bin/passthru.pl postgres 7853 2.5 1.5 505096 32860 ? S 10:58 0:01 postgres: postgres pro [local] SELECT nobody 7861 0.8 0.3 8624 7448 ? S 10:58 0:00 perl /www/cgi-bin/staffing/supplier/resumesearch.pl postgres 7862 2.5 1.5 505100 32860 ? S 10:58 0:01 postgres: postgres pro [local] SELECT postgres 7870 1.6 1.5 505100 32916 ? S 10:58 0:00 postgres: postgres pro [local] idle nobody 7871 0.5 0.3 8776 7608 ? S 10:58 0:00 perl /www/cgi-bin/staffing/orderdetail.pl postgres 7875 2.4 1.5 505100 32864 ? S 10:58 0:01 postgres: postgres pro [local] SELECT nobody 7891 0.9 0.3 8840 7680 ? S 10:58 0:00 perl /www/cgi-bin/staffing/csc/orderdetailedit.pl postgres 7896 5.6 2.2 505612 46236 ? S 10:58 0:02 postgres: postgres pro [local] SELECT nobody 7917 0.8 0.3 8644 7468 ? S 10:58 0:00 perl /www/cgi-bin/timecard/csc/force_process.pl postgres 7925 1.9 1.5 505100 32784 ? S 10:58 0:00 postgres: postgres pro [local] UPDATE nobody 7946 1.2 0.3 8640 7472 ? S 10:58 0:00 perl /www/cgi-bin/staffing/orderdetail.pl postgres 7948 4.1 1.7 505016 35372 ? R 10:58 0:01 postgres: postgres pro [local] SELECT nobody 7950 0.0 0.1 5384 2592 ? S 10:58 0:00 /www/bin/httpd -DSSL nobody 7971 0.0 0.1 5384 2512 ? S 10:58 0:00 /www/bin/httpd -DSSL nobody 7993 1.5 0.3 8844 7684 ? S 10:58 0:00 perl /www/cgi-bin/timecard/csc/create_invoice_search_form.pl nobody 7994 1.9 0.3 8688 7508 ? S 10:58 0:00 perl /www/cgi-bin/timecard/supplier/submit_days.pl nobody 8004 1.3 0.3 8732 7564 ? S 10:58 0:00 perl /www/cgi-bin/staffing/csc/financial_detail.pl postgres 8005 3.8 1.5 505100 32876 ? S 10:58 0:01 postgres: postgres pro [local] SELECT postgres 8007 0.7 1.1 505100 23268 ? S 10:58 0:00 postgres: postgres pro [local] SELECT postgres 8010 1.8 1.6 505096 34000 ? S 10:58 0:00 postgres: postgres pro [local] UPDATE nobody 8040 2.9 0.3 8844 7684 ? S 10:59 0:00 perl /www/cgi-bin/timecard/csc/create_invoice_search_form.pl postgres 8047 3.6 1.5 505100 32876 ? S 10:59 0:00 postgres: postgres pro [local] SELECT nobody 8058 3.1 0.3 8692 7528 ? S 10:59 0:00 perl /www/cgi-bin/login.pl nobody 8063 3.5 0.3 8716 7540 ? S 10:59 0:00 perl /www/cgi-bin/userapp/csc/contractor/basic_info/basic_info.ppostgres 8069 0.8 1.0 505028 22104 ? S 10:59 0:00 postgres: postgres pro [local] SELECT postgres 8074 4.5 1.5 505096 32904 ? S 10:59 0:00 postgres: postgres pro [local] idle nobody 8105 0.0 0.0 5260 1808 ? S 10:59 0:00 /www/bin/httpd -DSSL nobody 8109 7.5 0.3 8860 7684 ? S 10:59 0:00 perl /www/cgi-bin/timecard/supplier/process_days.pl postgres 8113 2.0 0.8 505100 16692 ? S 10:59 0:00 postgres: postgres pro [local] SELECT nobody 8114 17.0 0.3 8852 7672 ? S 10:59 0:00 perl /www/cgi-bin/timecard/supplier/process_days.pl postgres 8115 4.0 0.7 505100 15568 ? S 10:59 0:00 postgres: postgres pro [local] SELECT nobody 8117 21.3 0.3 8692 7528 ? S 10:59 0:00 perl /www/cgi-bin/login.pl postgres 8118 7.0 0.9 505028 19256 ? S 10:59 0:00 postgres: postgres pro [local] SELECT nobody 8123 29.5 0.3 8584 7396 ? S 10:59 0:00 perl /www/cgi-bin/passthru.pl postgres 8127 26.0 1.2 505100 25156 ? S 10:59 0:00 postgres: postgres pro [local] SELECT Gary DeSorbo isasitis@uchicago.edu Cell: 415.606.3857
It would seem that SELECT queries are active for reasonably long periods of time. I would suggest using pgmonitor run as postgres and, using the "query" functionality, grab the actual SQL being issued and run an EXPLAIN on it. It is likely that due to either table size, index or statistics differences between your development and production databases, you are experiencing the election of a different and less optimum query plan on one machine vs. the other. An "explain" would quickly confirm this. Hope this helps. Marc Mitchell - Senior Application Architect Enterprise Information Solutions, Inc. Downers Grove, IL 60515 marcm@eisolution.com ----- Original Message ----- From: "Gary DeSorbo" <isasitis@uchicago.edu> To: <pgsql-admin@postgresql.org> Sent: Wednesday, November 13, 2002 1:38 PM Subject: [ADMIN] Weird processes > I have been having some problems with my database/web server machine > and ma having difficulty in finding out what the problem is. I have > two machines configured exactly the same; one for development and one > for production. Pages on production are taking up to 10X longer to > load than the same pages on development. We have tested the line > speeds and they are comparable. > > I have been searching through the processes and have come across some > items that I have never seen on the machine before. The processes > listed below seem to be hanging around much longer than they should > be. Perl is the cgi and the only postgres user on this machine is the > web server. Any help would be greatly appreciated. Below is the > output: > > postgres 7633 2.6 2.2 505612 45968 ? S 10:57 0:02 > postgres: postgres pro [local] SELECT > nobody 7679 1.7 0.7 16792 15616 ? S 10:57 0:01 perl > /www/cgi-bin/reporting/report_search.pl > nobody 7682 1.5 0.3 8712 7548 ? S 10:57 0:01 perl > /www/cgi-bin/staffing/orderconfirmation.pl > postgres 7684 2.5 1.5 505100 32864 ? S 10:57 0:02 > postgres: postgres pro [local] SELECT > postgres 7685 1.4 1.6 505008 34508 ? S 10:57 0:01 > postgres: postgres pro [local] idle > postgres 7758 3.9 2.2 505088 45864 ? S 10:58 0:02 > postgres: postgres pro [local] SELECT > nobody 7768 0.7 0.3 8832 7672 ? S 10:58 0:00 perl > /www/cgi-bin/userapp/csc/contractor/contractorsearch.pl > postgres 7769 2.2 1.5 505096 32864 ? S 10:58 0:01 > postgres: postgres pro [local] SELECT > nobody 7800 0.0 0.1 5384 2596 ? S 10:58 0:00 > /www/bin/httpd -DSSL > nobody 7842 0.3 0.3 8768 7600 ? S 10:58 0:00 perl > /www/cgi-bin/passthru.pl > nobody 7846 0.4 0.3 8768 7600 ? S 10:58 0:00 perl > /www/cgi-bin/passthru.pl > postgres 7853 2.5 1.5 505096 32860 ? S 10:58 0:01 > postgres: postgres pro [local] SELECT > nobody 7861 0.8 0.3 8624 7448 ? S 10:58 0:00 perl > /www/cgi-bin/staffing/supplier/resumesearch.pl > postgres 7862 2.5 1.5 505100 32860 ? S 10:58 0:01 > postgres: postgres pro [local] SELECT > postgres 7870 1.6 1.5 505100 32916 ? S 10:58 0:00 > postgres: postgres pro [local] idle > nobody 7871 0.5 0.3 8776 7608 ? S 10:58 0:00 perl > /www/cgi-bin/staffing/orderdetail.pl > postgres 7875 2.4 1.5 505100 32864 ? S 10:58 0:01 > postgres: postgres pro [local] SELECT > nobody 7891 0.9 0.3 8840 7680 ? S 10:58 0:00 perl > /www/cgi-bin/staffing/csc/orderdetailedit.pl > postgres 7896 5.6 2.2 505612 46236 ? S 10:58 0:02 > postgres: postgres pro [local] SELECT > nobody 7917 0.8 0.3 8644 7468 ? S 10:58 0:00 perl > /www/cgi-bin/timecard/csc/force_process.pl > postgres 7925 1.9 1.5 505100 32784 ? S 10:58 0:00 > postgres: postgres pro [local] UPDATE > nobody 7946 1.2 0.3 8640 7472 ? S 10:58 0:00 perl > /www/cgi-bin/staffing/orderdetail.pl > postgres 7948 4.1 1.7 505016 35372 ? R 10:58 0:01 > postgres: postgres pro [local] SELECT > nobody 7950 0.0 0.1 5384 2592 ? S 10:58 0:00 > /www/bin/httpd -DSSL > nobody 7971 0.0 0.1 5384 2512 ? S 10:58 0:00 > /www/bin/httpd -DSSL > nobody 7993 1.5 0.3 8844 7684 ? S 10:58 0:00 perl > /www/cgi-bin/timecard/csc/create_invoice_search_form.pl > nobody 7994 1.9 0.3 8688 7508 ? S 10:58 0:00 perl > /www/cgi-bin/timecard/supplier/submit_days.pl > nobody 8004 1.3 0.3 8732 7564 ? S 10:58 0:00 perl > /www/cgi-bin/staffing/csc/financial_detail.pl > postgres 8005 3.8 1.5 505100 32876 ? S 10:58 0:01 > postgres: postgres pro [local] SELECT > postgres 8007 0.7 1.1 505100 23268 ? S 10:58 0:00 > postgres: postgres pro [local] SELECT > postgres 8010 1.8 1.6 505096 34000 ? S 10:58 0:00 > postgres: postgres pro [local] UPDATE > nobody 8040 2.9 0.3 8844 7684 ? S 10:59 0:00 perl > /www/cgi-bin/timecard/csc/create_invoice_search_form.pl > postgres 8047 3.6 1.5 505100 32876 ? S 10:59 0:00 > postgres: postgres pro [local] SELECT > nobody 8058 3.1 0.3 8692 7528 ? S 10:59 0:00 perl > /www/cgi-bin/login.pl > nobody 8063 3.5 0.3 8716 7540 ? S 10:59 0:00 perl > /www/cgi-bin/userapp/csc/contractor/basic_info/basic_info.ppostgres > 8069 0.8 1.0 505028 22104 ? S 10:59 0:00 postgres: > postgres pro [local] SELECT > postgres 8074 4.5 1.5 505096 32904 ? S 10:59 0:00 > postgres: postgres pro [local] idle > nobody 8105 0.0 0.0 5260 1808 ? S 10:59 0:00 > /www/bin/httpd -DSSL > nobody 8109 7.5 0.3 8860 7684 ? S 10:59 0:00 perl > /www/cgi-bin/timecard/supplier/process_days.pl > postgres 8113 2.0 0.8 505100 16692 ? S 10:59 0:00 > postgres: postgres pro [local] SELECT > nobody 8114 17.0 0.3 8852 7672 ? S 10:59 0:00 perl > /www/cgi-bin/timecard/supplier/process_days.pl > postgres 8115 4.0 0.7 505100 15568 ? S 10:59 0:00 > postgres: postgres pro [local] SELECT > nobody 8117 21.3 0.3 8692 7528 ? S 10:59 0:00 perl > /www/cgi-bin/login.pl > postgres 8118 7.0 0.9 505028 19256 ? S 10:59 0:00 > postgres: postgres pro [local] SELECT > nobody 8123 29.5 0.3 8584 7396 ? S 10:59 0:00 perl > /www/cgi-bin/passthru.pl > postgres 8127 26.0 1.2 505100 25156 ? S 10:59 0:00 > postgres: postgres pro [local] SELECT > > Gary DeSorbo > isasitis@uchicago.edu > Cell: 415.606.3857 > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org
Gary DeSorbo <isasitis@uchicago.edu> writes:
> I have been having some problems with my database/web server machine
> and ma having difficulty in finding out what the problem is. I have
> two machines configured exactly the same; one for development and one
> for production. Pages on production are taking up to 10X longer to
> load than the same pages on development.
Same size databases? Similar overall machine loads? And you *have*
done VACUUM ANALYZE recently on both machines?
regards, tom lane
every concurrent cgi script uses its own postgres connection in your case. you're going to run into more serious problems (e.g. empty pages for no reason) because of lack of possible postgres connections. so, 1) try mod_perl to speed up your perl scripts 2) think about writing a server which would provide cgi scripts with cached connections; you can $handle->prepare(...) the most common queries as well. anyway, it's not a postgres problem. if you wish to discuss that you may write me in private or try a www-developers mail-list. > I have been having some problems with my database/web server machine and > ma having difficulty in finding out what the problem is. I have two > machines configured exactly the same; one for development and one for > production. Pages on production are taking up to 10X longer to load than > the same pages on development. We have tested the line speeds and they > are comparable. > > I have been searching through the processes and have come across some > items that I have never seen on the machine before. The processes listed > below seem to be hanging around much longer than they should be. Perl is > the cgi and the only postgres user on this machine is the web server. > Any help would be greatly appreciated. Below is the output: > > postgres 7633 2.6 2.2 505612 45968 ? S 10:57 0:02 postgres: > postgres pro [local] SELECT > nobody 7679 1.7 0.7 16792 15616 ? S 10:57 0:01 perl > /www/cgi-bin/reporting/report_search.pl > nobody 7682 1.5 0.3 8712 7548 ? S 10:57 0:01 perl > /www/cgi-bin/staffing/orderconfirmation.pl > postgres 7684 2.5 1.5 505100 32864 ? S 10:57 0:02 postgres: > postgres pro [local] SELECT > postgres 7685 1.4 1.6 505008 34508 ? S 10:57 0:01 postgres: > postgres pro [local] idle > postgres 7758 3.9 2.2 505088 45864 ? S 10:58 0:02 postgres: > postgres pro [local] SELECT > nobody 7768 0.7 0.3 8832 7672 ? S 10:58 0:00 perl > /www/cgi-bin/userapp/csc/contractor/contractorsearch.pl > postgres 7769 2.2 1.5 505096 32864 ? S 10:58 0:01 postgres: > postgres pro [local] SELECT > nobody 7800 0.0 0.1 5384 2596 ? S 10:58 0:00 > /www/bin/httpd -DSSL > nobody 7842 0.3 0.3 8768 7600 ? S 10:58 0:00 perl > /www/cgi-bin/passthru.pl > nobody 7846 0.4 0.3 8768 7600 ? S 10:58 0:00 perl > /www/cgi-bin/passthru.pl > postgres 7853 2.5 1.5 505096 32860 ? S 10:58 0:01 postgres: > postgres pro [local] SELECT > nobody 7861 0.8 0.3 8624 7448 ? S 10:58 0:00 perl > /www/cgi-bin/staffing/supplier/resumesearch.pl > postgres 7862 2.5 1.5 505100 32860 ? S 10:58 0:01 postgres: > postgres pro [local] SELECT > postgres 7870 1.6 1.5 505100 32916 ? S 10:58 0:00 postgres: > postgres pro [local] idle > nobody 7871 0.5 0.3 8776 7608 ? S 10:58 0:00 perl > /www/cgi-bin/staffing/orderdetail.pl > postgres 7875 2.4 1.5 505100 32864 ? S 10:58 0:01 postgres: > postgres pro [local] SELECT > nobody 7891 0.9 0.3 8840 7680 ? S 10:58 0:00 perl > /www/cgi-bin/staffing/csc/orderdetailedit.pl > postgres 7896 5.6 2.2 505612 46236 ? S 10:58 0:02 postgres: > postgres pro [local] SELECT > nobody 7917 0.8 0.3 8644 7468 ? S 10:58 0:00 perl > /www/cgi-bin/timecard/csc/force_process.pl > postgres 7925 1.9 1.5 505100 32784 ? S 10:58 0:00 postgres: > postgres pro [local] UPDATE > nobody 7946 1.2 0.3 8640 7472 ? S 10:58 0:00 perl > /www/cgi-bin/staffing/orderdetail.pl > postgres 7948 4.1 1.7 505016 35372 ? R 10:58 0:01 postgres: > postgres pro [local] SELECT > nobody 7950 0.0 0.1 5384 2592 ? S 10:58 0:00 > /www/bin/httpd -DSSL > nobody 7971 0.0 0.1 5384 2512 ? S 10:58 0:00 > /www/bin/httpd -DSSL > nobody 7993 1.5 0.3 8844 7684 ? S 10:58 0:00 perl > /www/cgi-bin/timecard/csc/create_invoice_search_form.pl > nobody 7994 1.9 0.3 8688 7508 ? S 10:58 0:00 perl > /www/cgi-bin/timecard/supplier/submit_days.pl > nobody 8004 1.3 0.3 8732 7564 ? S 10:58 0:00 perl > /www/cgi-bin/staffing/csc/financial_detail.pl > postgres 8005 3.8 1.5 505100 32876 ? S 10:58 0:01 postgres: > postgres pro [local] SELECT > postgres 8007 0.7 1.1 505100 23268 ? S 10:58 0:00 postgres: > postgres pro [local] SELECT > postgres 8010 1.8 1.6 505096 34000 ? S 10:58 0:00 postgres: > postgres pro [local] UPDATE > nobody 8040 2.9 0.3 8844 7684 ? S 10:59 0:00 perl > /www/cgi-bin/timecard/csc/create_invoice_search_form.pl > postgres 8047 3.6 1.5 505100 32876 ? S 10:59 0:00 postgres: > postgres pro [local] SELECT > nobody 8058 3.1 0.3 8692 7528 ? S 10:59 0:00 perl > /www/cgi-bin/login.pl > nobody 8063 3.5 0.3 8716 7540 ? S 10:59 0:00 perl > /www/cgi-bin/userapp/csc/contractor/basic_info/basic_info.ppostgres > 8069 0.8 1.0 505028 22104 ? S 10:59 0:00 postgres: postgres > pro [local] SELECT > postgres 8074 4.5 1.5 505096 32904 ? S 10:59 0:00 postgres: > postgres pro [local] idle > nobody 8105 0.0 0.0 5260 1808 ? S 10:59 0:00 > /www/bin/httpd -DSSL > nobody 8109 7.5 0.3 8860 7684 ? S 10:59 0:00 perl > /www/cgi-bin/timecard/supplier/process_days.pl > postgres 8113 2.0 0.8 505100 16692 ? S 10:59 0:00 postgres: > postgres pro [local] SELECT > nobody 8114 17.0 0.3 8852 7672 ? S 10:59 0:00 perl > /www/cgi-bin/timecard/supplier/process_days.pl > postgres 8115 4.0 0.7 505100 15568 ? S 10:59 0:00 postgres: > postgres pro [local] SELECT > nobody 8117 21.3 0.3 8692 7528 ? S 10:59 0:00 perl > /www/cgi-bin/login.pl > postgres 8118 7.0 0.9 505028 19256 ? S 10:59 0:00 postgres: > postgres pro [local] SELECT > nobody 8123 29.5 0.3 8584 7396 ? S 10:59 0:00 perl > /www/cgi-bin/passthru.pl > postgres 8127 26.0 1.2 505100 25156 ? S 10:59 0:00 postgres: > postgres pro [local] SELECT > > Gary DeSorbo > isasitis@uchicago.edu > Cell: 415.606.3857 > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > > >
On Thu, Nov 14, 2002 at 10:47:20AM +0300, dima wrote: > 2) think about writing a server which would provide cgi scripts with > cached connections; you can $handle->prepare(...) the most common > queries as well. This seems like a common requirement. Are there any such tools which can be run in a web server (or similar) environment to keep a pool of postgresql connections, and perhaps cache common queries also? Regards, Chris -- Chris Miles chris_pg002@psychofx.com
Chris Miles wrote: > On Thu, Nov 14, 2002 at 10:47:20AM +0300, dima wrote: > >>2) think about writing a server which would provide cgi scripts with >>cached connections; you can $handle->prepare(...) the most common >>queries as well. > > This seems like a common requirement. Are there any such tools which > can be run in a web server (or similar) environment to keep a pool > of postgresql connections, and perhaps cache common queries also? I worked (& work now) for several web software development companies each having its own software (for corporate use only). i started a project in c++ to resolve db pooling task in common, but it is in the early alpha stage for now due to lack of spare time (i haven't installed a unix os on my new laptop as well since i'm waiting for freebsd 5.0 to be released). it will be available free (artistic license i guess) till the new year probably. for now, i can recommend using shared memory to save db handles & compiled queries in perl or c++.
What you're looking for is SQLRelay. You will need to work a little bit around the DBI driver to get the cached connections, but since the driver uses its native interface, this is possible (or you can scrap DBI altogether- not recommended). Get it here: http://taonix.org/ because firstworks.com has been down for months. It's works great. The other probably better option (though not always possible to use) would be mod_perl and Apache::DBI connection pooling. This would be the easiest solution because it would require minimal-to-none code changes. While it would be possible to collect db handles in shared memory, it would still require a persistently running daemon- SQLRelay does essentially that, only it has more features. Apache::DBI caches the handles in Apache space and hands you the handle that has exactly the same connection parameters and is more configurable as a connection pooler. Good luck. On Thursday, November 14, 2002, at 03:03 AM, Chris Miles wrote: > On Thu, Nov 14, 2002 at 10:47:20AM +0300, dima wrote: >> 2) think about writing a server which would provide cgi scripts with >> cached connections; you can $handle->prepare(...) the most common >> queries as well. > > This seems like a common requirement. Are there any such tools which > can be run in a web server (or similar) environment to keep a pool > of postgresql connections, and perhaps cache common queries also? > > Regards, > Chris > > -- > Chris Miles > chris_pg002@psychofx.com > > ---------------------------(end of > broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > > ><><><><><><><><>< AgentM agentm@cmu.edu
Unfortunately Apache::DBI handles per-process connections only. So, almost any httpd child will hold all the connections. If you use user sessions as well, you'll run even into more serious troubles. > What you're looking for is SQLRelay. You will need to work a little bit > around the DBI driver to get the cached connections, but since the > driver uses its native interface, this is possible (or you can scrap DBI > altogether- not recommended). Get it here: > http://taonix.org/ > because firstworks.com has been down for months. > It's works great. The other probably better option (though not always > possible to use) would be mod_perl and Apache::DBI connection pooling. > This would be the easiest solution because it would require > minimal-to-none code changes. > While it would be possible to collect db handles in shared memory, > it would still require a persistently running daemon- SQLRelay does > essentially that, only it has more features. Apache::DBI caches the > handles in Apache space and hands you the handle that has exactly the > same connection parameters and is more configurable as a connection pooler. > Good luck. > > On Thursday, November 14, 2002, at 03:03 AM, Chris Miles wrote: > >> On Thu, Nov 14, 2002 at 10:47:20AM +0300, dima wrote: >> >>> 2) think about writing a server which would provide cgi scripts with >>> cached connections; you can $handle->prepare(...) the most common >>> queries as well. >> >> >> This seems like a common requirement. Are there any such tools which >> can be run in a web server (or similar) environment to keep a pool >> of postgresql connections, and perhaps cache common queries also? >> >> Regards, >> Chris >> >> -- >> Chris Miles >> chris_pg002@psychofx.com >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 3: if posting/reading through Usenet, please send an appropriate >> subscribe-nomail command to majordomo@postgresql.org so that your >> message can get through to the mailing list cleanly >> >> > ><><><><><><><><>< > AgentM > agentm@cmu.edu > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > >
At 10:47 14.11.2002 -0500, A.M. wrote the following message: >What you're looking for is SQLRelay. one can not use sql relay as fake postgresql server? Thanks in advance. Tomaz