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
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
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
11 matches
Mail list logo
