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_natts is accessed.
Tom, how should this be tested? I assume some loop of the same query
over and over again.
I'd be satisfied by a demonstration of no meaningful difference in
pgbench numbers.
It's *probably* not a problem, but you never know if you don't check...
I doubt there's any measurable difference, but I can do a pgbench run to
make sure.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
