Re: [HACKERS] WAL Re-Writes

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

Re: [HACKERS] WAL Re-Writes

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

Re: [HACKERS] WAL Re-Writes

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 >

Re: [HACKERS] WAL Re-Writes

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

Re: [HACKERS] WAL Re-Writes

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,

Re: [HACKERS] WAL Re-Writes

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

Re: [HACKERS] WAL Re-Writes

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

Re: [HACKERS] WAL Re-Writes

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 >>>

Re: [HACKERS] WAL Re-Writes

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

Re: [HACKERS] WAL Re-Writes

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

Re: [HACKERS] WAL Re-Writes

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

Re: [HACKERS] WAL Re-Writes

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

[HACKERS] WAL Re-Writes

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