Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts value? This is not a zero-cost improvement.
Tom, how should this be tested? I assume some loop of the same query
over an
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >>> Patch applied. Thanks.
> >>> I added a comment about the unused bits in the header file.
> >> Has anyone bothered to measure the overhead added by having to mask to
> >> fetch
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> What? I'm completely lost here. What does log_temp_files have to do with
> the bits on the tuple header?
Nothing, it looks like Bruce replied to the wrong message at one point
while these two threads were active ...
regards
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts value? This is not a zero-cost improvement.
I haven't tested it. Agreed, it does add an AND operation to places
where t_n
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Patch applied. Thanks.
I added a comment about the unused bits in the header file.
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts value? This is not a zero-cost imp
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > SHOW ALL has:
>
> >log_temp_files | -1 | Log
> > the use of temporary files larger than th
>
> Yeah, but if you do "SET log_temp_files = -1", does it still say that?
> I'm worried
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Has anyone bothered to measure the overhead added by having to mask to
>> fetch or store the natts value? This is not a zero-cost improvement.
> Tom, how should this be tested? I assume some loop of the same query
> over and over aga
Bruce Momjian <[EMAIL PROTECTED]> writes:
> SHOW ALL has:
>log_temp_files | -1 | Log the
> use of temporary files larger than th
Yeah, but if you do "SET log_temp_files = -1", does it still say that?
I'm worried that will change it to -1024.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Patch applied. Thanks.
> > I added a comment about the unused bits in the header file.
>
> Has anyone bothered to measure the overhead added by having to mask to
> fetch or store the natts value? This is not a zero-cost improvement.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Patch applied. Thanks.
> > I added a comment about the unused bits in the header file.
>
> Has anyone bothered to measure the overhead added by having to mask to
> fetch or store the natts value? This is not a zero-cost improvement.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Patch applied. Thanks.
> I added a comment about the unused bits in the header file.
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts value? This is not a zero-cost improvement.
re
Patch applied. Thanks.
I added a comment about the unused bits in the header file.
---
Heikki Linnakangas wrote:
> Hi,
>
> We're running out of infomask bits in the tuple header. I bumped into
> this as I tried to appl
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I believe it would actually be even better to combine the t_natts and
> t_infomask fields to a single 32-bit infomask field.
That's not happening, because the alignment is wrong ...unless maybe
we switch this field to fall before t_ctid, but t
Hi,
We're running out of infomask bits in the tuple header. I bumped into
this as I tried to apply both the phantom command ids patch, and the HOT
patch simultaneously. They both require one infomask bit, so they
conflicted.
This has been discussed before; I think the best approach is to use
14 matches
Mail list logo