| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | <nickf(at)ontko(dot)com>, <shridhar_daithankar(at)persistent(dot)co(dot)in>, "Pgsql-Performance(at)Postgresql(dot) Org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Sanity check requested |
| Date: | 2003-07-17 15:57:08 |
| Message-ID: | 200307170857.08837.josh@agliodbs.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Nick,
> I'll try that approach while testing. Is it the case that the sort memory
> is allocated for each connection and becomes unavailable to other processes
> while the connection exists? If so, since I'm using a connection pool, I
> should be able to control total usage precisely. Without a connection pool,
> I could start starving the rest of the system for resources if the number
> of users spiked unexpectedly. Correct?
Wrong, actually. Sort memory is allocated *per sort*, not per connnection or
per query. So a single complex query could easily use 4xsort_mem if it has
several merge joins ... and a pooled connection could use many times sort_mem
depending on activity. Thus connection pooling does not help you with
sort_mem usage at all, unless your pooling mechanism can control the rate at
which queries are fed to the planner.
--
Josh Berkus
Aglio Database Solutions
San Francisco
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nick Fankhauser | 2003-07-17 16:11:41 | Re: Sanity check requested |
| Previous Message | Nick Fankhauser | 2003-07-17 15:41:35 | Re: Sanity check requested |