On 01/18/2013 11:50 PM, Robert Haas wrote:
> On Fri, Jan 18, 2013 at 10:36 AM, Merlin Moncure wrote:
>> Any scenario that involves non-trivial amount of investigation or
>> development should result in us pulling the patch for rework and
>> resubmission in later 'festit's closing time as they
On Fri, Jan 18, 2013 at 10:36 AM, Merlin Moncure wrote:
> Any scenario that involves non-trivial amount of investigation or
> development should result in us pulling the patch for rework and
> resubmission in later 'festit's closing time as they say :-).
Amen.
--
Robert Haas
EnterpriseDB: h
On Fri, Jan 18, 2013 at 8:57 AM, Atri Sharma wrote:
>
> Hello all,
>
> Sorry for the delay in updating the hackers list with the current status.
>
> I recently did some profiling using perf on PostgreSQL 9.2 with and without
> our patch.
>
> I noticed that maximum time is being spent on heapgettu
On 18-Jan-2013, at 17:04, Craig Ringer wrote:
> On 12/14/2012 09:57 PM, Amit Kapila wrote:
>>>
>>> I need to validate the vacuum results. It's possible that this is
>>> solvable by tweaking xmin check inside vacuum. Assuming that's fixed,
>>> the question stands: do the results justify the cha
On Fri, Jan 18, 2013 at 5:34 AM, Craig Ringer wrote:
> On 12/14/2012 09:57 PM, Amit Kapila wrote:
>>>
>>> I need to validate the vacuum results. It's possible that this is
>>> solvable by tweaking xmin check inside vacuum. Assuming that's fixed,
>>> the question stands: do the results justify the
On 12/14/2012 09:57 PM, Amit Kapila wrote:
>>
>> I need to validate the vacuum results. It's possible that this is
>> solvable by tweaking xmin check inside vacuum. Assuming that's fixed,
>> the question stands: do the results justify the change? I'd argue
>> 'maybe'
> We can try with change (ass
On Thursday, December 13, 2012 8:02 PM Merlin Moncure wrote:
> On Thu, Dec 13, 2012 at 7:06 AM, Hari Babu
> wrote:
> > Please find the review of the patch.
>
>
> Thanks for detailed review!
>
> > Basic stuff:
> >
> > - Patch applies with offsets.
> > - Compiles cleanly with no warn
On Thu, Dec 13, 2012 at 7:06 AM, Hari Babu wrote:
> Please find the review of the patch.
Thanks for detailed review!
> Basic stuff:
>
> - Patch applies with offsets.
> - Compiles cleanly with no warnings
> - Regression Test pass.
>
> Code Review:
> -
> 1. Better
On Thu, Dec 13, 2012 at 6:36 PM, Hari Babu wrote:
> On Thu, Dec 7, 2012 at 7:56 PM, Hari babu
> wrote:
>
> >>On Thu, Dec 6, 2012 at 8:52 PM, Merlin Moncure
> wrote:
>
> >>Thanks for that -- that's fairly comprehensive I'd say. I'm quite
>
> ** **
>
> >>interested in that benchmarki
On Thu, Dec 7, 2012 at 7:56 PM, Hari babu
wrote:
>>On Thu, Dec 6, 2012 at 8:52 PM, Merlin Moncure wrote:
>>Thanks for that -- that's fairly comprehensive I'd say. I'm quite
>>interested in that benchmarking framework as well. Do you need help
>>setting up the scripts?
>Presently I
On Thu, Dec 6, 2012 at 8:52 PM, Merlin Moncure wrote:
>Thanks for that -- that's fairly comprehensive I'd say. I'm quite
>interested in that benchmarking framework as well. Do you need help
>setting up the scripts?
Presently I am testing with pgbench custom query option & taking IO & VM
statist
On Thu, Dec 6, 2012 at 3:59 AM, Amit Kapila wrote:
> On Thursday, November 22, 2012 3:00 AM Greg Smith wrote:
>> On 11/16/12 9:03 AM, Merlin Moncure wrote:
>> > Atri ran some quick n dirty tests to see if there
>> > were any regressions. He benched a large scan followed by vacuum. So
>> > far, r
On Thursday, November 22, 2012 3:00 AM Greg Smith wrote:
> On 11/16/12 9:03 AM, Merlin Moncure wrote:
> > Atri ran some quick n dirty tests to see if there
> > were any regressions. He benched a large scan followed by vacuum. So
> > far, results are inconclusive so better testing methodologies wi
Merlin Moncure escribió:
> Maybe abstracting 'last xid cache' along with hint bit management out
> of both transam.c and tqual.c into something like 'hints.c' is
> appropriate, but that's a more invasive change.
It would be good to have such a patch to measure/compare performance of
both approac
On 11/16/12 9:03 AM, Merlin Moncure wrote:
Atri ran some quick n dirty tests to see if there
were any regressions. He benched a large scan followed by vacuum. So
far, results are inconclusive so better testing methodologies will
definitely be greatly appreciated. One of the challenges with wor
On Fri, Nov 16, 2012 at 7:33 PM, Merlin Moncure wrote:
> On Fri, Nov 16, 2012 at 4:32 AM, Amit Kapila
> wrote:
> > On Thursday, November 15, 2012 10:19 PM Merlin Moncure wrote:
> >> On Thu, Nov 15, 2012 at 10:25 AM, Amit Kapila
> >> wrote:
> >
> >>
> >> Sure, although in scans we are using ring
On Thu, Nov 15, 2012 at 6:42 PM, Jeff Davis wrote:
> On Tue, 2012-11-06 at 17:55 -0600, Merlin Moncure wrote:
>> So given that -- the patch simple adds an extra check when/where hint
>> bit status is checked in the visibility routines (currently, only
>> HeapTupleSatisfiesMVCC is done but all the
On Fri, Nov 16, 2012 at 4:32 AM, Amit Kapila wrote:
> On Thursday, November 15, 2012 10:19 PM Merlin Moncure wrote:
>> On Thu, Nov 15, 2012 at 10:25 AM, Amit Kapila
>> wrote:
>
>>
>> Sure, although in scans we are using ring buffer as well so in
>> practical sense the results are pretty close.
>>
On Thursday, November 15, 2012 10:19 PM Merlin Moncure wrote:
> On Thu, Nov 15, 2012 at 10:25 AM, Amit Kapila
> wrote:
>
> Sure, although in scans we are using ring buffer as well so in
> practical sense the results are pretty close.
>
> > b. Considering sometimes people want VACUUM to run when
On Tue, 2012-11-06 at 17:55 -0600, Merlin Moncure wrote:
> So given that -- the patch simple adds an extra check when/where hint
> bit status is checked in the visibility routines (currently, only
> HeapTupleSatisfiesMVCC is done but all the applicable visibility
> routines should be done). Basica
On Thu, Nov 15, 2012 at 10:25 AM, Amit Kapila wrote:
>> IMNSHO. deferring non-critical i/o from foreground process to
>> background process is generally good.
>
> Yes, in regard of deferring you are right.
> However in this case may be when foreground process has to mark page dirty
> due to hint-b
On Thursday, November 15, 2012 9:27 PM Merlin Moncure wrote:
> On Thu, Nov 15, 2012 at 4:39 AM, Amit Kapila
> wrote:
> >>In each visibility function (except HeapTupleSatisfiesVacuum() ), an
> >> addition check has been added to check if the commit status of Xmin
> or Xmax
> >> of a tuple can be >r
On Thu, Nov 15, 2012 at 4:39 AM, Amit Kapila wrote:
>>In each visibility function (except HeapTupleSatisfiesVacuum() ), an
>> addition check has been added to check if the commit status of Xmin or Xmax
>> of a tuple can be >retrieved from the cache.
>
>
>
> 1. From your explanation and code,
On Thursday, November 15, 2012 2:02 AM Atri Sharma wrote:
On Thu, Nov 15, 2012 at 12:42 AM, Atri Sharma wrote:
On Wed, Nov 7, 2012 at 9:47 PM, Merlin Moncure wrote:
On Wed, Nov 7, 2012 at 6:01 AM, Amit Kapila wrote:
>> >> Following the sig is a first cut at a patch (written by Atri) that
>
On Thu, Nov 15, 2012 at 12:42 AM, Atri Sharma wrote:
>
>
>
> On Wed, Nov 7, 2012 at 9:47 PM, Merlin Moncure wrote:
>
>> On Wed, Nov 7, 2012 at 6:01 AM, Amit Kapila
>> wrote:
>> >> >> Following the sig is a first cut at a patch (written by Atri) that
>> >> >> attempts to mitigate hint bit i/o pe
On Wed, Nov 7, 2012 at 9:47 PM, Merlin Moncure wrote:
> On Wed, Nov 7, 2012 at 6:01 AM, Amit Kapila
> wrote:
> >> >> Following the sig is a first cut at a patch (written by Atri) that
> >> >> attempts to mitigate hint bit i/o penalty when many pages worth of
> >> >> tuples are sequentially writt
On Wed, Nov 7, 2012 at 6:01 AM, Amit Kapila wrote:
>> >> Following the sig is a first cut at a patch (written by Atri) that
>> >> attempts to mitigate hint bit i/o penalty when many pages worth of
>> >> tuples are sequentially written out with the same transaction id.
>> >> There have been other a
>> Sent: Wednesday, November 07, 2012 5:26 AM
> > >> To: PostgreSQL-development
> > >> Cc: Atri Sharma
> > >> Subject: [HACKERS] WIP patch for hint bit i/o mitigation
> > >>
> > >> Following the sig is a first cut at a patch (written
> -Original Message-
> From: Atri Sharma [mailto:atri.j...@gmail.com]
> Sent: Wednesday, November 07, 2012 4:02 PM
> To: Amit Kapila
> Cc: Merlin Moncure; PostgreSQL-development
> Subject: Re: [HACKERS] WIP patch for hint bit i/o mitigation
>
> On 07-Nov-201
gt; Subject: [HACKERS] WIP patch for hint bit i/o mitigation
>>
>> Following the sig is a first cut at a patch (written by Atri) that
>> attempts to mitigate hint bit i/o penalty when many pages worth of
>> tuples are sequentially written out with the same transaction id.
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Merlin Moncure
> Sent: Wednesday, November 07, 2012 5:26 AM
> To: PostgreSQL-development
> Cc: Atri Sharma
> Subject: [HACKERS] WIP patch for hint bit i/o mitigation
>
>
Following the sig is a first cut at a patch (written by Atri) that
attempts to mitigate hint bit i/o penalty when many pages worth of
tuples are sequentially written out with the same transaction id.
There have been other attempts to deal with this problem that fit
niche cases (especially those tha
32 matches
Mail list logo