On Thu, Jun 26, 2014 at 10:37 AM, Shaun Thomas
wrote:
> On 06/26/2014 09:22 AM, AJ Weber wrote:
>
> I sent the details as identified by pgAdmin III.
>>
>
> Interesting. Either there is a bug in pgAdmin, or you're connecting to a
> different database that is missing the primary key. What is the E
On Mon, Feb 10, 2014 at 3:03 PM, Heikki Linnakangas wrote:
> On 02/10/2014 09:52 PM, M Putz wrote:
>
>>
>> Hello,
>>
>> While analyzing performance, we encountered the following phenomenon,
>>
>> SELECT sum(pow(.5*generate_series,.5))
>> FROM generate_series(1,100);
>>
>> is much much
I don't remember the exact error message, but basically, if I set it to
anything else but fsync, when I start PostgreSQL, it tells me that the new
method is not available on my platform.
Sébastien
On Mon, Sep 17, 2012 at 6:56 AM, Ivan Voras wrote:
> On 14/09/2012 22:19, Sébastien Lori
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 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
