On Jan 27, 2008 4:08 PM, Greg Smith <[EMAIL PROTECTED]> wrote:
>
> More segments means more disk space taken up with them and a longer crash
> recovery. Those are the downsides; if you can live with those there's no
> reason to run at <100 if that works for you. Fine-tuning here isn't
> really t
Tom Lane wrote:
> "Stephen Denne" <[EMAIL PROTECTED]> writes:
> > So dropping the fk constraint and index results in
> successful query execution with constant memory usage. Does
> this confirm that the memory leak you found is the one I was
> suffering from?
>
> Well, it confirms that you were
On Jan 25, 2008 11:36 AM, David Brain <[EMAIL PROTECTED]> wrote:
> I'd appreciate some assistance in working through what would be the
> optimal configuration for the following situation.
>
> We currently have one large DB (~1.2TB on disk), that essentially
> consists of 1 table with somewhere in t
"Stephen Denne" <[EMAIL PROTECTED]> writes:
> So dropping the fk constraint and index results in successful query execution
> with constant memory usage. Does this confirm that the memory leak you found
> is the one I was suffering from?
Well, it confirms that you were suffering from that memory
Hi David,
I have been running few tests with 8.2.4 and here is what I have seen:
If fysnc=off is not an option (and it should not be an option :-) )
then commit_delay=10 setting seems to help a lot in my OLTP runs.
Granted it will delay your transactions a bit, but the gain is big
considering
On Fri, 25 Jan 2008, Tory M Blue wrote:
I doubled the checkpoint segments yesterday and have not seen any
warnings. Will run with segments of 100 for a while and see how things
look.. Anyway to make sure that there is not a number between 50 and
100 that makes more sense?
More segments means m
On Jan 27, 2008 5:01 PM, Thomas Lozza <[EMAIL PROTECTED]> wrote:
> Thanks for the advice.
> I used the default settings before, thought though that vacuum was a bit
> aggressive, ie, using too many resources. Now its taking very long. So
> will have to find reasonable settings in between I guess.
>
Thanks for the advice.
I used the default settings before, thought though that vacuum was a bit
aggressive, ie, using too many resources. Now its taking very long. So
will have to find reasonable settings in between I guess.
On the other hand, if I keep the fsm_page number high enough, the system
On Jan 27, 2008 12:29 PM, Dean Rasheed <[EMAIL PROTECTED]> wrote:
> >> Is there any way that I can see what execution plan is being used
> >> internally by the functions?
> >>
> >
> > Not directly, but you can do this:
> >
> >
> > postgres=# PREPARE p (int4) AS SELECT id FROM foo WHERE lower(name)
>>"Stephen Denne" <[EMAIL PROTECTED]> writes:
>>> I altered the update statement slightly, and reran the query.
>>> The altered query has been running over 3 hours now,
>>> without using lots of memory (38M private bytes).
>>> 2046 temp files were created (2.54GB worth),
>>> which have recently cha
Dnia 27-01-2008, N o godzinie 17:29 +, Dean Rasheed pisze:
> The CONTEXT is very useful, particularly when functions call other
> functions, since it gives the call stack (presumably only for SQL and
> PL/pgSQL functions). For top-level queries I would ideally like the
> CONTEXT to log the SQL
>> Is there any way that I can see what execution plan is being used
>> internally by the functions?
>>
>
> Not directly, but you can do this:
>
>
> postgres=# PREPARE p (int4) AS SELECT id FROM foo WHERE lower(name) LIKE
> 'foo' ORDER BY id OFFSET 0 LIMIT $1;
> PREPARE
>
> postgres=# EXPLAI
Matthew wrote:
On Fri, 25 Jan 2008, Greg Smith wrote:
If you're seeing <100TPS you should consider if it's because you're
limited by how fast WAL commits can make it to disk. If you really
want good insert performance, there is no substitute for getting a
disk controller with a good battery-b
13 matches
Mail list logo
