Charles Sprickman wrote:
> On Tue, 27 Feb 2007, Dave Page wrote:
>
>> Magnus Hagander wrote:
>>>
>>> Just as a datapoint, we did try to use mnogosearch for the
>>> postgresql.org website+archives search, and it fell over completely.
>>> Indexing took way too long, and we had search times several t
On Tue, Feb 27, 2007 at 01:33:47PM +, Dave Page wrote:
> When we outgrow PostgreSQL & Tsearch2, then, well, we'll need to stop
> pretending to be Google...
Just for the record: Google has been known to sponsor sites in need with
Google Minis and such earlier -- I don't know what their[1] polic
Steinar H. Gunderson wrote:
> On Tue, Feb 27, 2007 at 01:33:47PM +, Dave Page wrote:
>> When we outgrow PostgreSQL & Tsearch2, then, well, we'll need to stop
>> pretending to be Google...
>
> Just for the record: Google has been known to sponsor sites in need with
> Google Minis and such earli
On Wed, 28 Feb 2007, Dave Page wrote:
Steinar H. Gunderson wrote:
On Tue, Feb 27, 2007 at 01:33:47PM +, Dave Page wrote:
When we outgrow PostgreSQL & Tsearch2, then, well, we'll need to stop
pretending to be Google...
Just for the record: Google has been known to sponsor sites in need wi
Oleg Bartunov wrote:
> Guys, current tsearch2 should works with millions of documents.
...
> Search itself is incredibly fast !
Oh, I know - you and Teodor have done a wonderful job.
Regards, Dave.
---(end of broadcast)---
TIP 3: Have you check
As the subject says. A quite puzzling situation: we not only upgraded the
software, but also the hardware:
Old system:
PG 7.4.x on Red Hat 9 (yes, it's not a mistake!!!)
P4 HT 3GHz with 1GB of RAM and IDE hard disk (120GB, I believe)
New system:
PG 8.2.3 on Fedora Core 4
Athlon64 X2 4200+
Carlos Moreno <[EMAIL PROTECTED]> writes:
> I would have expected a mind-blowing increase in responsiveness and
> overall performance. However, that's not the case --- if I didn't know
> better, I'd probably tend to say that it is indeed the opposite
> (performance seems to have deteriorated)
D
Tom Lane wrote:
Carlos Moreno <[EMAIL PROTECTED]> writes:
I would have expected a mind-blowing increase in responsiveness and
overall performance. However, that's not the case --- if I didn't know
better, I'd probably tend to say that it is indeed the opposite
(performance seems to have d
Carlos Moreno wrote:
Tom Lane wrote:
Carlos Moreno <[EMAIL PROTECTED]> writes:
I would have expected a mind-blowing increase in responsiveness and
overall performance. However, that's not the case --- if I didn't know
better, I'd probably tend to say that it is indeed the opposite
(perfo
Rodrigo Gonzalez wrote:
I've since discovered a problem that *may* be related to the
deterioration
of the performance *now* --- but that still does not explain the machine
choking since last night, so any comments or tips are still most
welcome.
[...]
And the problem that *may* be related
Are there any issues with client libraries version mismatching
backend version?
I'm just realizing that the client software is still running on the
same machine (not the same machine where PG is running) that
has PG 7.4 installed on it, and so it is using the client libraries 7.4
Any chance tha
On Sun, Feb 25, 2007 at 23:11:01 +0100,
Peter Kovacs <[EMAIL PROTECTED]> wrote:
> A related question:
> Is it sufficient to disable write cache only on the disk where pg_xlog
> is located? Or should write cache be disabled on both disks?
With recent linux kernels you may also have the option to
On Tue, Feb 27, 2007 at 15:35:13 +1030,
Shane Ambler <[EMAIL PROTECTED]> wrote:
>
> From all that I have heard this is another advantage of SCSI disks -
> they honor these settings as you would expect - many IDE/SATA disks
> often say "sure I'll disable the cache" but continue to use it or don
On Wed, Feb 28, 2007 at 05:21:41 +1030,
Shane Ambler <[EMAIL PROTECTED]> wrote:
>
> The difference between SCSI and IDE/SATA in this case is a lot if not
> all IDE/SATA drives tell you that the cache is disabled when you ask it
> to but they either don't actually disable it or they don't retai
Hi,
I am sorry if it is a repeat question but I want to know if database
performance will decrease if I increase the max-connections to 2000. At present
it is 100.
I have a requirement where the clent want 2000 simultaneous users and the only
option we have now is to in crease the database con
On 3/1/07, Shiva Sarna <[EMAIL PROTECTED]> wrote:
I am sorry if it is a repeat question but I want to know if database
performance will decrease if I increase the max-connections to 2000. At
present it is 100.
Most certainly. Adding connections over 200 will degrade performance
dramatically.
Jonah H. Harris wrote:
> On 3/1/07, Shiva Sarna <[EMAIL PROTECTED]> wrote:
>> I am sorry if it is a repeat question but I want to know if database
>> performance will decrease if I increase the max-connections to 2000. At
>> present it is 100.
>
> Most certainly. Adding connections over 200 will
Joshua D. Drake wrote:
Jonah H. Harris wrote:
On 3/1/07, Shiva Sarna <[EMAIL PROTECTED]> wrote:
I am sorry if it is a repeat question but I want to know if database
performance will decrease if I increase the max-connections to 2000. At
present it is 100.
Most certainly. Adding connections ov
18 matches
Mail list logo
