On Mon, Feb 8, 2016 at 8:16 PM, Andres Freund wrote:
>
> On 2016-02-08 10:38:55 +0530, Amit Kapila wrote:
> > I think deciding it automatically without user require to configure it,
> > certainly has merits, but what about some cases where user can get
> > benefits by configuring themselves like t
On Mon, Feb 8, 2016 at 8:11 PM, Robert Haas wrote:
>
> On Mon, Feb 8, 2016 at 12:08 AM, Amit Kapila
wrote:
> > I think deciding it automatically without user require to configure it,
> > certainly has merits, but what about some cases where user can get
> > benefits by configuring themselves like
On 2016-02-08 10:38:55 +0530, Amit Kapila wrote:
> I think deciding it automatically without user require to configure it,
> certainly has merits, but what about some cases where user can get
> benefits by configuring themselves like the cases where we use
> PG_O_DIRECT flag for WAL (with o_direct,
On Mon, Feb 8, 2016 at 12:08 AM, Amit Kapila wrote:
> I think deciding it automatically without user require to configure it,
> certainly has merits, but what about some cases where user can get
> benefits by configuring themselves like the cases where we use
> PG_O_DIRECT flag for WAL (with o_dir
On Wed, Feb 3, 2016 at 7:12 PM, Robert Haas wrote:
>
> On Wed, Feb 3, 2016 at 7:28 AM, Amit Kapila
wrote:
> > On further testing, it has been observed that misaligned writes could
> > cause reads even when blocks related to file are not in-memory, so
> > I think what Jan is describing is right.
On Wed, Feb 3, 2016 at 7:28 AM, Amit Kapila wrote:
> On further testing, it has been observed that misaligned writes could
> cause reads even when blocks related to file are not in-memory, so
> I think what Jan is describing is right. The case where there is
> absolutely zero chance of reads is w
On Wed, Feb 3, 2016 at 11:12 AM, Amit Kapila
wrote:
>
> On Mon, Feb 1, 2016 at 8:05 PM, Jim Nasby
wrote:
>>
>> On 1/31/16 3:26 PM, Jan Wieck wrote:
>>>
>>> On 01/27/2016 08:30 AM, Amit Kapila wrote:
operation. Now why OS couldn't find the corresponding block in
memory is that, whi
On Mon, Feb 1, 2016 at 8:05 PM, Jim Nasby wrote:
> On 1/31/16 3:26 PM, Jan Wieck wrote:
>
>> On 01/27/2016 08:30 AM, Amit Kapila wrote:
>>
>>> operation. Now why OS couldn't find the corresponding block in
>>> memory is that, while closing the WAL file, we use
>>> POSIX_FADV_DONTNEED if wal_leve
On 1/31/16 3:26 PM, Jan Wieck wrote:
On 01/27/2016 08:30 AM, Amit Kapila wrote:
operation. Now why OS couldn't find the corresponding block in
memory is that, while closing the WAL file, we use
POSIX_FADV_DONTNEED if wal_level is less than 'archive' which
lead to this problem. So with this exp
On 01/27/2016 08:30 AM, Amit Kapila wrote:
operation. Now why OS couldn't find the corresponding block in
memory is that, while closing the WAL file, we use
POSIX_FADV_DONTNEED if wal_level is less than 'archive' which
lead to this problem. So with this experiment, the conclusion is that
though
On Thu, Jan 28, 2016 at 1:34 AM, james wrote:
> On 27/01/2016 13:30, Amit Kapila wrote:
>
>>
>> Thoughts?
>>
>> Are the decreases observed with SSD as well as spinning rust?
>
>
The test is done with WAL on SSD and data on spinning rust, but I
think the results should be similar if we would have
On 27/01/2016 13:30, Amit Kapila wrote:
Thoughts?
Are the decreases observed with SSD as well as spinning rust?
I might imagine that decreasing the wear would be advantageous,
especially if the performance decrease is less with low read latency.
--
Sent via pgsql-hackers mailing list (p
As discussed previously about WAL Re-Writes [1], I have
done some investigation in that area which I would like to
share.
Currently we always write WAL in 8KB blocks, which could
lead to a lot of re-write of data for small-transactions. Consider
the case where the amount to be written is usually
13 matches
Mail list logo