Forwarding to -performance
From: Alan Hodgson [mailto:[EMAIL PROTECTED]
On Friday 09 June 2006 12:41, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> Has anyone actually done any testing on this? Specifically, I'm
> wondering if the benefit of adding 2 more drives to a RAID10 outweighs
> whatever pen
On Fri, 2006-06-09 at 14:41, Jim C. Nasby wrote:
> AFAIK, the reason why seperating pg_xlog from the base files provides so
> much performance is because the latency on pg_xlog is critical: a
> transaction can't commit until all of it's log data is written to disk
> via fsync, and if you're trying
AFAIK, the reason why seperating pg_xlog from the base files provides so
much performance is because the latency on pg_xlog is critical: a
transaction can't commit until all of it's log data is written to disk
via fsync, and if you're trying to fsync frequently on the same drive as
the data tables
On Fri, Jun 09, 2006 at 02:23:04PM +0200, Domenico - Sal. F.lli Riva wrote:
> Hello,
>
> During insert or update, potgresql write in pgsql_tmp directory and so
> performance are very poor.
pgsql_tmp is used if a query runs out of work_mem, so you can try
increasing that.
> My configuration is:
>
On Fri, Jun 09, 2006 at 12:40:26PM +0300, Andrus wrote:
> > Actually It looks to me like the sorting is the slow part of this query.
> > Maybe if you did create an index on both kuupaev and kellaaeg it might
> > make the sorting faster.
>
> Thank you. It makes query fast.
>
> > Or maybe you could
I think that having an API for backup functionality would definitely be useful.
Just my 2 cents...
Paul
On 6/8/06, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> Personally I think it would be neat. For example the admin-tool guys> would be able to get a dump without invoking an ex
Hello,
During insert or update, potgresql write in pgsql_tmp directory and so
performance are very poor.
My configuration is:
Work mem10240
Effective_cache_size 3
Shared buffers 9000
Max_fsm_pages 35000
Wal Buffers
Tom,
> Because it doesn't help --- the system still has to do the sort.
It can help a lot in this case.
kuupaev is sales date
kellaaeg is sales time
Postgres can use kuupaev index to fetch first 100 rows plus a number of more
rows whose kellaaeg value is equal to kellaaeg in 100 th row. I have
> Actually It looks to me like the sorting is the slow part of this query.
> Maybe if you did create an index on both kuupaev and kellaaeg it might
> make the sorting faster.
Thank you. It makes query fast.
> Or maybe you could try increasing the server's
> work mem. The sort will be much slower
> Btw. have you run ANALYZE on the table recently?
I have autovacuum with default statitics settings running so I expect that
it is analyzed.
> What is the number
> of distinct values in the 'kuupaev' column?
select count(distinct kuupaev) from makse
returns 61
kuupaev is sales date.
So this
10 matches
Mail list logo
