Ah I see... I thought that by running the vacuum more often, its cost would
be divided in a more or less linear fashion, with a base constant cost.
While I read about the vacuum process, I did not check the source code or
even read about the actual algorithm, so I am sorry for having asked a
nonsen
> I am pondering about this... My thinking is that since *_scale_factor need
> to be set manually for largish tables (>1M), why not
> set autovacuum_vacuum_scale_factor and autovacuum_analyze_scale_factor, and
> increase the value of autovacuum_vacuum_threshold to, say, 1, and
> autovacuum_ana
I am not able to set wal_sync_method to anything but fsync on FreeBSD 9.0
for a DB created on ZFS (I have not tested on UFS). Is that expected ? Has
it anything to do with running on EC2 ?
Sébastien
I am pondering about this... My thinking is that since *_scale_factor need
to be set manually for largish tables (>1M), why not
set autovacuum_vacuum_scale_factor and autovacuum_analyze_scale_factor, and
increase the value of autovacuum_vacuum_threshold to, say, 1, and
autovacuum_analyze_thresh
I am looking at changing all of the foreign key definitions to be deferrable
(initially immediate). Then during a few scenarios performed by the
application, set all foreign key constraints to be deferred (initially
deferred) for that given transaction.
My underlying question/concern is "will
Hi, Craig
On 14 September 2012 18:29, Craig James wrote:
> Did you compile the AMD code on the AMD system?
Yes
And it is optimized for Generic-x86-64 (CONFIG_GENERIC_CPU).
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http:
On Fri, Sep 14, 2012 at 12:40 AM, Nikolay Ulyanitsky wrote:
> Hi
> I compiled the 3.6-rc5 kernel with the same config from 3.5.3 and got
> the 15-20% performance drop of PostgreSQL 9.2 on AMD chipsets (880G,
> 990X).
>
Did you compile the AMD code on the AMD system?
We use a different open-sourc
On 14 September 2012 11:45, Daniel Farina wrote:
> Did you tell LKML? It seems like a kind of change that could be found
> using git bisect of Linux, albiet laboriously.
Hi, Daniel
I sent it to linux-ker...@vger.kernel.org on Fri, 14 Sep 2012 10:47:44
+0300.
On 14 September 2012 17:56, Marcos
Regards, Nikolay.
Like Daniel said to you, I encourage to inform all your findings to the
LKML to
report all these problems.
Only one las t question: Did you tune the postgresql.conf for every
system? or
Did you use the default configuration ?
Best wishes
On 09/14/2012 04:45 AM, Daniel Farin
On Fri, Sep 14, 2012 at 12:40 AM, Nikolay Ulyanitsky wrote:
> Hi
> I compiled the 3.6-rc5 kernel with the same config from 3.5.3 and got
> the 15-20% performance drop of PostgreSQL 9.2 on AMD chipsets (880G,
> 990X).
>
> CentOS 6.3 x86_64
> PostgreSQL 9.2
> cpufreq scaling_governor - performance
>
On Wed, Sep 12, 2012 at 7:00 PM, Jeff Janes wrote:
> Regarding the wiki page on reporting slow queries:
> We currently recommend EXPLAIN ANALYZE over just EXPLAIN. Should we
> recommend EXPLAIN (ANALYZE, BUFFERS) instead? I know I very often
> wish I could see that data. I don't think turning b
Hi
I compiled the 3.6-rc5 kernel with the same config from 3.5.3 and got
the 15-20% performance drop of PostgreSQL 9.2 on AMD chipsets (880G,
990X).
CentOS 6.3 x86_64
PostgreSQL 9.2
cpufreq scaling_governor - performance
# /etc/init.d/postgresql initdb
# echo "fsync = off" >> /var/lib/pgsql/data/
12 matches
Mail list logo
