Tom Lane wrote:
> This patch was originally submitted before we realized that pg_stats
> failed to distinguish the effects of committed vs rolled-back
> transactions (which was fixed about three months ago); and we also
> recently fixed several other bugs such as losing stats data for shared
> cata
Tom Lane <[EMAIL PROTECTED]> wrote:
> >> o Error correction for n_dead_tuples
> Also, I'm still quite unhappy that the patch converts the tracking of
> n_dead_tuples into a dead-reckoning system in which incremental changes
> are continually applied without any feedback that'd prevent the value
On Tue, 21 Aug 2007, ITAGAKI Takahiro wrote:
Does anyone have a way to measure the performance difference by
bgwriter_lru_xxx ? I have no performance results not only of the patch
but also of those parameters. I'd like to use those test cases to compare
manual and automatic tunings of lru parame
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> o Error correction for n_dead_tuples
>>
>> This shows as waiting on another patch. Again, I am thinking to
>> keep it for 8.4.
> It was waiting on the "vacuum oldestxmin" patch, which didn't make it to
> 8.3. I don't care
Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> Bruce Momjian wrote:
> > o Automatic adjustment of bgwriter_lru_maxpages
> >
> > We show this as waiting for performance results. I am thinking we
> > should hold this for 8.4.
>
> Agreed. I spent close to a week trying different ben
Joshua D. Drake wrote:
> Alvaro Herrera wrote:
>> Joshua D. Drake wrote:
>>> Heikki Linnakangas wrote:
Joshua D. Drake wrote:
>
>>> I guess my point is, if the patch looks good and does not appear to hurt
>>> anything, why not apply it? At least that way we can start to review the
>>> progres
Joshua D. Drake wrote:
I guess my point is, if the patch looks good and does not appear to hurt
anything, why not apply it? At least that way we can start to review the
progress of the feature itself as it starts to see use.
I don't think that's a very good criterion. We need to have goo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Heikki Linnakangas wrote:
> Joshua D. Drake wrote:
>> Heikki Linnakangas wrote:
>>> Joshua D. Drake wrote:
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
>> o Automatic adjustment of bgwriter_lru_maxpages
\
>>> I would expect a fairl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alvaro Herrera wrote:
> Joshua D. Drake wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Heikki Linnakangas wrote:
>>> Joshua D. Drake wrote:
>> I guess my point is, if the patch looks good and does not appear to hurt
>> anything, why
Joshua D. Drake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Heikki Linnakangas wrote:
> > Joshua D. Drake wrote:
> >> Heikki Linnakangas wrote:
> >>> Bruce Momjian wrote:
> o Automatic adjustment of bgwriter_lru_maxpages
>
> We show this as waiting for perf
Joshua D. Drake wrote:
> Heikki Linnakangas wrote:
>> Joshua D. Drake wrote:
>>> Heikki Linnakangas wrote:
Bruce Momjian wrote:
> o Automatic adjustment of bgwriter_lru_maxpages
>
> We show this as waiting for performance results. I am thinking we
> should hold t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Heikki Linnakangas wrote:
> Joshua D. Drake wrote:
>> Heikki Linnakangas wrote:
>>> Bruce Momjian wrote:
o Automatic adjustment of bgwriter_lru_maxpages
We show this as waiting for performance results. I am thinking we
Joshua D. Drake wrote:
> Heikki Linnakangas wrote:
>> Bruce Momjian wrote:
>>> o Automatic adjustment of bgwriter_lru_maxpages
>>>
>>> We show this as waiting for performance results. I am thinking we
>>> should hold this for 8.4.
>> Agreed. I spent close to a week trying different b
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > o Error correction for n_dead_tuples
> >
> > This shows as waiting on another patch. Again, I am thinking to
> > keep it for 8.4.
>
> It was waiting on the "vacuum oldestxmin" patch, which didn't make it to
> 8.3. I don't care fo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
>> o Automatic adjustment of bgwriter_lru_maxpages
>>
>> We show this as waiting for performance results. I am thinking we
>> should hold this for 8.4.
>
> Agreed. I spent close to a week
Bruce Momjian wrote:
> o Automatic adjustment of bgwriter_lru_maxpages
>
> We show this as waiting for performance results. I am thinking we
> should hold this for 8.4.
Agreed. I spent close to a week trying different benchmarks and
configurations and simple test cases on a test se
Here is the current 8.3 patch status:
http://developer.postgresql.org/index.php/Todo:PatchStatus
As you can see we have two major patches remaining, tsearch2 and HOT.
Tom is working on tsearch2 now and Paven just posted an updated HOT
patch. (Only the GIT (group index tuples) patch didn
17 matches
Mail list logo
