Jim Mercer wrote:
> On Thu, May 02, 2002 at 09:45:45PM -0400, mlw wrote:
> > Jim Mercer wrote:
> > > On Thu, May 02, 2002 at 09:14:03PM -0400, mlw wrote:
> > > > Jim Mercer wrote:
> > > > > On Thu, May 02, 2002 at 08:41:30PM -0400, mlw wrote:
> > > > > > A mission statement is like a tie.
> > > >
Horst Herb wrote:
> > > Branding. Phone support lines. Legal departments/Lawsuit prevention.
> Figuring
> > > out how to prevent open source from stealing the thunder by duplicating
> ^^
> > > features. And building a _product_.
> Oops.
Thomas Lockhart wrote:
>
> > PostgreSQL, Inc perhaps has that as a game plan.
> > I'm not so much concerned about exactly what PG, Inc is planning to offer
> > as a proprietary piece - I'm purist enough that I worry about what this
> > signals for their future direction.
> Hmm. What has kept repl
Mitch Vincent wrote:
>
> This is one of the not-so-stomped boxes running PostgreSQL -- I've never
> restarted PostgreSQL on it since it was installed.
> 12:03pm up 122 days, 7:54, 1 user, load average: 0.08, 0.11, 0.09
> I had some index corruption problems in 6.5.3 but since 7.0.X I haven't
Tom Samplonius wrote:
> On Sun, 26 Nov 2000, Alain Toussaint wrote:
> > > "I have all sorts of client apps, connecting in different ways, to
> > > my server. Some of the clients are leaving their connections open,
> > > but unused. How can I prevent running out of backends, and boot
> > > the inac
Don Baccus wrote:
> At 12:07 AM 11/26/00 -0500, Alain Toussaint wrote:
> >how about having a middle man between apache (or aolserver or any other
> >clients...) and PosgreSQL ??
> >that middleman could be configured to have 16 persistant connections,every
> >clients would deal with the middleman i
Note: CC'd to Hackers, as this has wandered into deeper feature issues.
Tom Lane wrote:
> GH <[EMAIL PROTECTED]> writes:
> > Do the "persistent-connected" Postgres backends ever timeout or die?
> No. A backend will sit patiently for the client to send it another
> query or close the connection.
The Hermit Hacker wrote:
> I'm tryin to figure out how to speed up udmsearch when run under
> postgresql, and am being hit by atrocious performance when using a LIKE
> query ... the query looks like:
> SELECT ndict.url_id,ndict.intag
> FROM ndict,url
> WHERE ndict.word_id=1971739852
>AND ur
