On Wednesday 06 August 2003 08:34, Yaroslav Mazurak wrote:
> Hi All!
>
>
> I have installed PostgreSQL 7.3.2 on FreeBSD 4.7, running on PC with
> CPU Pentium II 400MHz and 384Mb RAM.
Version 7.3.4 is just out - probably worth upgrading as soon as it's
convenient.
> Prob
Yaroslav Mazurak <[EMAIL PROTECTED]> writes:
>>> fsync = false
>> I'd turn fsync back on - unless you don't mind losing your data after a crash.
> This is temporary performance solution - I want get SELECT query result
> first, but current performance is too low.
Disabling fsync will not h
On Thu, 7 Aug 2003, Richard Huxton wrote:
> But this parameter controls how much memory can be allocated to sorts - I
> don't see how PG can figure out a reasonable maximum by itself.
One could have one setting for the total memory usage and pg could use
statistics or some heuristics to use the
On Thursday 07 August 2003 09:24, Yaroslav Mazurak wrote:
> > IIRC there is a limit on filesystem cache on freeBSD. 300MB by default.
> > If that is the case, you might have to raise it to make
> > effective_cache_size really effective..
>
> "Try various sysctls" says nothing for me. I want u
> Mem: 71M Active, 23M Inact, 72M Wired, 436K Cache, 48M Buf, 208M Free
> Swap: 368M Total, 2852K Used, 366M Free
>
> It's right that I can figure that I can use 384M (total RAM) - 72M
> (wired) - 48M (buf) = 264M for PostgreSQL.
> Hence, if I set effective_cache_size to 24M (3072 8K
Hi All!
I have installed PostgreSQL 7.3.2 on FreeBSD 4.7, running on PC with
CPU Pentium II 400MHz and 384Mb RAM.
Problem is that SQL statement (see below) is running too long. With
current WHERE clause 'SUBSTR(2, 2) IN ('NL', 'NM') return 25 records.
With 1 record, SELECT time is about 50
Yaroslav Mazurak <[EMAIL PROTECTED]> writes:
> Current postgresql.conf settings (some) are:
> max_locks_per_transaction = 16
This strikes me as a really bad idea --- you save little space by
reducing it from the default, and open yourself up to unexpected failures.
> wal_buffers = 256
Tha
On Thu, 7 Aug 2003, Yaroslav Mazurak wrote:
> Hi All!
>
> Shridhar Daithankar wrote:
>
> > On 7 Aug 2003 at 10:05, Yaroslav Mazurak wrote:
>
> >>>It needs to reflect how much cache the system is using - try the "free"
> >>>command to see figures.
>
> >>I'm not found "free" ut
On Thursday 07 August 2003 17:30, Yaroslav Mazurak wrote:
> Hi All!
>
>
> First, thanks for answers!
>
> Richard Huxton wrote:
> > On Thursday 07 August 2003 09:24, Yaroslav Mazurak wrote:
> >>>IIRC there is a limit on filesystem cache on freeBSD. 300MB by default.
> >>>If that is the case, y
On Thu, 7 Aug 2003, Yaroslav Mazurak wrote:
> scott.marlowe wrote:
>
> > On Thu, 7 Aug 2003, Yaroslav Mazurak wrote:
>
> >>Shridhar Daithankar wrote:
>
> > That's a nice theory, but it doesn't work out that way. About every two
> > months someone shows up wanting postgresql to use all the mem
On 6 Aug 2003 at 15:42, Yaroslav Mazurak wrote:
> >>sort_mem = 131072
> > This sort_mem value is *very* large - that's 131MB for *each sort* that gets
> > done. I'd suggest trying something in the range 1,000-10,000. What's probably
> > happening with the error above is that PG is allocating ridi
Hi, All!
Richard Huxton wrote:
On Thursday 07 August 2003 17:30, Yaroslav Mazurak wrote:
Richard Huxton wrote:
On Thursday 07 August 2003 09:24, Yaroslav Mazurak wrote:
PG's memory use can be split into four areas (note - I'm not a developer so
this could be wrong).
1. Shared memory - vital
On 7 Aug 2003 at 10:05, Yaroslav Mazurak wrote:
> > It needs to reflect how much cache the system is using - try the "free"
> > command to see figures.
>
> I'm not found "free" utility on FreeBSD 4.7. :(
Grr.. I don't like freeBSD for it's top output.Active/inactive/Wired.. Grr..
why can'
On Thu, 7 Aug 2003, Yaroslav Mazurak wrote:
> Hi All!
>
>
> Richard Huxton wrote:
>
> >>>On Wednesday 06 August 2003 08:34, Yaroslav Mazurak wrote:
>
> sort_mem = 131072
>
> >>>This sort_mem value is *very* large - that's 131MB for *each sort* that
>
> It's not TOO la
scott.marlowe wrote:
On Thu, 7 Aug 2003, Yaroslav Mazurak wrote:
Shridhar Daithankar wrote:
That's a nice theory, but it doesn't work out that way. About every two
months someone shows up wanting postgresql to use all the memory in their
box for caching and we wind up explaining that the kern
Hi All!
Shridhar Daithankar wrote:
On 7 Aug 2003 at 10:05, Yaroslav Mazurak wrote:
It needs to reflect how much cache the system is using - try the "free"
command to see figures.
I'm not found "free" utility on FreeBSD 4.7. :(
Grr.. I don't like freeBSD for it's top output.Active/inactive/
Hi All!
First, thanks for answers!
Richard Huxton wrote:
On Thursday 07 August 2003 09:24, Yaroslav Mazurak wrote:
IIRC there is a limit on filesystem cache on freeBSD. 300MB by default.
If that is the case, you might have to raise it to make
effective_cache_size really effective..
On Thu, 2003-08-07 at 12:04, Yaroslav Mazurak wrote:
> scott.marlowe wrote:
>
> > On Thu, 7 Aug 2003, Yaroslav Mazurak wrote:
>
> >>Shridhar Daithankar wrote:
>
[snip]
> > My guess is that this is exactly what's happening to you, you're using so
> > much memory that the machine is running out a
On Thursday 07 August 2003 08:05, Yaroslav Mazurak wrote:
> Hi All!
>
> Richard Huxton wrote:
> >>>On Wednesday 06 August 2003 08:34, Yaroslav Mazurak wrote:
> sort_mem = 131072
> >>>
> >>>This sort_mem value is *very* large - that's 131MB for *each sort* that
>
> It's not TOO large *for
Hi All!
Tom Lane wrote:
Yaroslav Mazurak <[EMAIL PROTECTED]> writes:
fsync = false
I'd turn fsync back on - unless you don't mind losing your data after a crash.
This is temporary performance solution - I want get SELECT query result
first, but current performance is too low.
Disabl
Hi All!
Richard Huxton wrote:
On Wednesday 06 August 2003 08:34, Yaroslav Mazurak wrote:
sort_mem = 131072
This sort_mem value is *very* large - that's 131MB for *each sort* that
It's not TOO large *for PostgreSQL*. When I'm inserting a large amount
of data into tables, sort_mem helps. Valu
Hi All!
First, thanks for answers.
Richard Huxton wrote:
On Wednesday 06 August 2003 08:34, Yaroslav Mazurak wrote:
Version 7.3.4 is just out - probably worth upgrading as soon as it's
convenient.
Has version 7.3.4 significant performance upgrade relative to 7.3.2?
I've downloaded versi
>> On Wednesday 06 August 2003 08:34, Yaroslav Mazurak wrote:
>
>> Version 7.3.4 is just out - probably worth upgrading as soon as it's
>> convenient.
>
> Has version 7.3.4 significant performance upgrade relative to 7.3.2?
> I've downloaded version 7.3.4, but not installed yet.
No, but ther
"Yaroslav Mazurak" <[EMAIL PROTECTED]>
> Problem is that SQL statement (see below) is running too long. With
> current WHERE clause 'SUBSTR(2, 2) IN ('NL', 'NM') return 25 records.
> With 1 record, SELECT time is about 50 minutes and takes approx. 120Mb
> RAM. With 25 records SELECT takes about
24 matches
Mail list logo
