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 and
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
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
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,
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 or store the natts
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 apply
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.
I
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.
SHOW
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.
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 again.
I'd
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 that will
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
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 that
14 matches
Mail list logo
