Re: Database connection closed after each request?

On Sun, Jul 26, 2009 at 10:17 PM, Amitay Dobo<amit...@gmail.com> wrote: > So to sum up: I vote up connection pooling. Where do I sign up? Thread hijacking. Thanks, always appreciated. -- Glenn Maynard --~--~-~--~~~---~--~~ You received this message be

Re: Database connection closed after each request?

On Fri, Jul 24, 2009 at 9:02 PM, Glenn Maynard<gl...@zewt.org> wrote: > By the way, I switched my connections from TCP to a Unix socket with > local authentication and it dropped to 5-10ms.  (I suspect it was If you're using a connection pooler, you don't want to disconnect and re

Re: Database connection closed after each request?

ause > it would have even worse side effects (see: "spinning up a server > process ties up a DB handle for as long as the process lives?") and > could quite realistically cause resource starvation. 8-16 connections from the 8-16 backend threads I'm starting are going to swamp

Re: Database connection closed after each request?

es no sense. I suspect the actual formula is something like pow(0.9, (seconds_latency / 0.050)); in other words, 500ms latency would imply 34.8% as many sales. That's pretty believable. -- Glenn Maynard --~--~-~--~~~---~--~~ You received this message because you a

Re: Database connection closed after each request?

anything but bug reports right now with the tracker so (understandably) backlogged from the release freeze. So relax, I'm not jumping head-first into this. -- Glenn Maynard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Gro

Signals API

(site:http://docs.djangoproject.com/en/ "The registered receiver to disconnect." - did not match any documents). It seems intended to be public, but I can only find disconnect mentioned in 1.0-porting-guide (site:http://docs.djangoproject.com/en/ signal disconnect). -- Gle

Re: Database connection closed after each request?

gs, like not being able to use "local" authentication in Postgres); just to eliminate needless database reconnections. -- Glenn Maynard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users"

Re: Database connection closed after each request?

On Thu, Jul 23, 2009 at 10:02 PM, Carlos A. Carnero Delgado<carloscarn...@gmail.com> wrote: > On Thu, Jul 23, 2009 at 5:24 PM, Glenn Maynard<gl...@zewt.org> wrote: >> Why is each thread's database connection closed after each request? > > I believe that this is related

Re: PostgreSQL Stored Procedure in ordinary Django query expression?

upport for this in Django 1.1 that I just > haven't found yet? I'd like to know this, too. It'd be an excellent way to execute complex SQL without having to drop out of the ORM entirely: hide the logic in a function, giving it a simple interface that the ORM can easily digest without

Database connection closed after each request?

spending 25% of the time for the request on something that shouldn't be necessary at all. -- Glenn Maynard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group,

Setting tzinfo for DateTimeFields with Postgresql - workaround

pport, too. As long as TIME_ZONE and the tzinfo of times passed to queries are the same it should work fine, which is all I need. -- Glenn Maynard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users&

Re: GROUP BY

On Jan 27, 2:50 am, Malcolm Tredinnick wrote: > > I don't care if it takes more than one line, though there is, in > > fact :), a big difference between taking more than one line and having > > to bypass the public API. > > Only semantically, when you're trying to

Re: GROUP BY

On Jan 26, 11:42 pm, Malcolm Tredinnick wrote: > That's because it doesn't exist. Django isn't meant to completely > replace the need for SQL, for a start. I was assuming it was possible because the extra() API already seems to try to avoid forcing people to drop out

Re: GROUP BY

On Jan 26, 10:20 pm, Russell Keith-Magee wrote: > I'm a little bit confused as to what you think is happening here - > what do you mean by "other than a simple column"? The default > aggregate grouping is effectively by object instance; the > implementation means that

GROUP BY

How are aggregates grouped on anything other than a simple column? db/sql/query.py set_group_by suggests that this might work, to (for example) group together dollar amounts: Table.objects.extra(select={"dollars": "cents/100"}).values ("dollars").aggregate(...) That doesn't throw an error (it