Re: [PERFORM] viewing source code

2007-12-21 Thread Trevor Talbot
not as if objecting to this requires a bunch of abstract hyperbole, just a simple it's not worth the effort and it's considered a bad idea to put security-senstive data inside PL function bodies. On 12/20/07, Joshua D. Drake [EMAIL PROTECTED] wrote: On Thu, 20 Dec 2007 10:47:53 -0800 Trevor Talbot

Re: [PERFORM] viewing source code

2007-12-21 Thread Trevor Talbot
I wrote: That's it. A very simple problem. It was hinted to me off-list that my mail was fanning the flames, so to clarify: when I say things like the above, I mean conceptually. I think there might be a shared pool of knowledge that says it's anything but simple in practical terms, but that

Re: [PERFORM] viewing source code

2007-12-20 Thread Trevor Talbot
On 12/20/07, Joshua D. Drake [EMAIL PROTECTED] wrote: Roberts, Jon wrote: This really is a needed feature to make PostgreSQL more attractive to businesses. A more robust security model that better follows commercial products is needed for adoption. I would argue that commercial products

Re: [PERFORM] TB-sized databases

2007-11-30 Thread Trevor Talbot
On 11/29/07, Gregory Stark [EMAIL PROTECTED] wrote: Simon Riggs [EMAIL PROTECTED] writes: On Wed, 2007-11-28 at 14:48 +0100, Csaba Nagy wrote: In fact an even more useful option would be to ask the planner to throw error if the expected cost exceeds a certain threshold... Tom's previous

Re: [PERFORM] Curious about dead rows.

2007-11-13 Thread Trevor Talbot
On 11/13/07, Alvaro Herrera [EMAIL PROTECTED] wrote: Jean-David Beyer wrote: Andrew Sullivan wrote: I'm not a private support organisation; please send your replies to the list, not me. Sorry. Most of the lists I send to have ReplyTo set, but a few do not. And then I forget. If

Re: [PERFORM] Performance on 8CPU's and 32GB of RAM

2007-09-05 Thread Trevor Talbot
On 9/5/07, Scott Marlowe [EMAIL PROTECTED] wrote: On 9/5/07, Carlo Stonebanks [EMAIL PROTECTED] wrote: Right, additionally NTFS is really nothing to use on any serious disc array. Do you mean that I will not see any big improvement if I upgrade the disk subsystem because the client is

Re: [PERFORM] Performance on 8CPU's and 32GB of RAM

2007-09-05 Thread Trevor Talbot
On 9/5/07, Scott Marlowe [EMAIL PROTECTED] wrote: On 9/5/07, Trevor Talbot [EMAIL PROTECTED] wrote: On 9/5/07, Scott Marlowe [EMAIL PROTECTED] wrote: On 9/5/07, Carlo Stonebanks [EMAIL PROTECTED] wrote: Right, additionally NTFS is really nothing to use on any serious disc array

Re: [PERFORM] utilising multi-cpu/core machines?

2007-09-05 Thread Trevor Talbot
On 9/5/07, Thomas Finneid [EMAIL PROTECTED] wrote: how does pg utilise multi cpus/cores, i.e. does it use more than one core? and possibly, how, are there any documentation about this. PostgreSQL creates a new process to handle each connection to the database. Multiple sessions can therefore

Re: [PERFORM] Update table performance

2007-08-09 Thread Trevor Talbot
On 8/9/07, Michael Stone [EMAIL PROTECTED] wrote: On Thu, Aug 09, 2007 at 06:04:09PM +0530, Merlin Moncure wrote: keep an eye for the HOT feature which will hopefully make 8.3 that will highly reduce the penalty for (small) updates in many cases. Is there an overview somewhere about how this