Please see the attached version 4.4 of HOT WIP patch. I have
fixed couple of bugs in the earlier version posted. Other than
that there are not any significant changes in the patch.
The row-level fragmentation had a bug where we were
unintentionally sorting the line pointers array more than
once.
Updated patch:
I went through the "high traffic" areas and levelled them up to using the new
macros to avoid "detoasting" smaller arguments. They key areas are really
btree operators since they have a noticeable effect on sorts, especially index
builds, when the data being sorted fits in memory.
Joachim Wieland <[EMAIL PROTECTED]> writes:
> On Tue, Mar 13, 2007 at 11:52:38AM -0400, Tom Lane wrote:
>> Why do you need to tell that? IMHO, once the DefineCustomFoo function
>> has been executed, it should be exactly like any other variable (other
>> than having a funny name).
> For example fo
On Tue, Mar 13, 2007 at 11:52:38AM -0400, Tom Lane wrote:
> > Then what is the criterion to tell what is a custom variable and what isn't?
> Why do you need to tell that? IMHO, once the DefineCustomFoo function
> has been executed, it should be exactly like any other variable (other
> than having
Joachim Wieland <[EMAIL PROTECTED]> writes:
> On Tue, Mar 13, 2007 at 11:08:52AM -0400, Tom Lane wrote:
>> My point here that you shouldn't be using var->group to make any
>> semantic choices. That's supposed to be a label for user convenience,
>> nothing else.
> Then what is the criterion to tel
On Tue, Mar 13, 2007 at 11:08:52AM -0400, Tom Lane wrote:
> Joachim Wieland <[EMAIL PROTECTED]> writes:
> > On Tue, Mar 13, 2007 at 10:19:54AM -0400, Tom Lane wrote:
> >> Well, they *are* strings as long as they're "custom". Once a
> >> DefineCustomFoo has been executed, there (should be) no diffe
Joachim Wieland <[EMAIL PROTECTED]> writes:
> On Tue, Mar 13, 2007 at 10:19:54AM -0400, Tom Lane wrote:
>> Well, they *are* strings as long as they're "custom". Once a
>> DefineCustomFoo has been executed, there (should be) no difference
>> between a "custom" variable and a hard-wired one.
> The
On Tue, Mar 13, 2007 at 10:19:54AM -0400, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > It's not just a bug. There's code missing.
> > The code seems to assume that all custom variables are strings. There are
> > about half a dozen Assert(variable->vartype == PGC_STRING) through
Tom Lane wrote:
> The thing that I was wondering about is the same Joachim mentioned:
> how is it that the regression test ever worked? The answer is that
> it's not really testing custom variables, because it doesn't try to
> set plperl.use_strict until after plperl has been loaded into the
> cur
Peter Eisentraut wrote:
> Joachim Wieland wrote:
> > Attached is the long-awaited guc patch that makes values fall back
> > to their default values when they got removed (or commented) from
> > the configuration file. This has always been a source of confusion.
>
> I have applied your patch with so
Gregory Stark <[EMAIL PROTECTED]> writes:
> It's not just a bug. There's code missing.
> The code seems to assume that all custom variables are strings. There are
> about half a dozen Assert(variable->vartype == PGC_STRING) throughout the
> patch. That's not true, plperl's use_strict is a boolean
Joachim Wieland wrote:
On Tue, Mar 13, 2007 at 08:22:17AM +, Gregory Stark wrote:
The code seems to assume that all custom variables are strings. There are
about half a dozen Assert(variable->vartype == PGC_STRING) throughout the
patch. That's not true, plperl's use_strict is a boolean an
Heikki Linnakangas wrote:
I am, but I doubt that's it. The response times are dominated by I/O, so
any increase in lock contention would hardly show up. And the patch is
only adding one GetOldestXmin call every 1000 scanned pages, which is
Sorry, should be "every 100 scanned pages". The argum
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
I ran two 24h test runs with DBT-2, one with the patch and one without.
To get comparable, predictable results, I turned autovacuum off and run
a manual vacuum in a loop on the stock-table alone.
As expected, the steady-state of the stock table
Heikki Linnakangas wrote:
> I ran two 24h test runs with DBT-2, one with the patch and one without.
> To get comparable, predictable results, I turned autovacuum off and run
> a manual vacuum in a loop on the stock-table alone.
>
> As expected, the steady-state of the stock table is smaller wit
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Was this revisited?
Arranging the tests has taken me longer than I thought, but I now
finally have the hardware and DBT-2 set up. I just finished a pair of 2h
tests with autovacuum off, and continuous vacuum of the stock table. I'm
trying to g
On Tue, Mar 13, 2007 at 08:22:17AM +, Gregory Stark wrote:
> The code seems to assume that all custom variables are strings. There are
> about half a dozen Assert(variable->vartype == PGC_STRING) throughout the
> patch. That's not true, plperl's use_strict is a boolean and we have
> DefineCusto
On Tue, Mar 13, 2007 at 05:09:15PM +0900, ITAGAKI Takahiro wrote:
>
> Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
>
> > Can we distinguish mingw case from others so that we could ifdef out
> > the extra fflush()?
> > > The buffered stderr might be a bug of mingw
>
> After a little research, I found
"Tom Lane" <[EMAIL PROTECTED]> writes:
> It's a release-note item ... assuming that it doesn't get reverted in
> the near future. Could we have some attention to the all-red buildfarm?
It's not just a bug. There's code missing.
The code seems to assume that all custom variables are strings. T
Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> Can we distinguish mingw case from others so that we could ifdef out
> the extra fflush()?
> > The buffered stderr might be a bug of mingw
After a little research, I found that MSDN says the buffered stderr is
a specifications on Windows somehow, not a b
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> This is a pretty major user-visible change. While I'm strongly in
>> favour of it it seems like there ought to be some documentation file
>> touched by this, no? Or have I missed it?
> In my opinion, and possibly that of others
21 matches
Mail list logo
