I wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Again though, I really don't think it matters.
> Agreed, it's unlikely this would be a significant change either way.
Just for the record, pgbench numbers seem unaffected by this patch
(on Fedora Core 6 x86_64).
rega
Gregory Stark <[EMAIL PROTECTED]> writes:
> That's not really the point. The problem is that the compiler usually can't
> deduce which function you're calling or even which set of functions you might
> be calling. So, for example, the compiler will have trouble determining which
> variables may be
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> It sounds like a fine idea from the point of view of flexibility. But as far
>> as faster... I guess it depends on how often HeapTupleSatisfiesVisibility is
>> used in contexts where the compiler is able to opti
Gregory Stark <[EMAIL PROTECTED]> writes:
> It sounds like a fine idea from the point of view of flexibility. But as far
> as faster... I guess it depends on how often HeapTupleSatisfiesVisibility is
> used in contexts where the compiler is able to optimize away the conditionals
> or the cpu is abl
"Martijn van Oosterhout" writes:
> On Sat, Mar 24, 2007 at 09:37:07PM +, Gregory Stark wrote:
>
>> It sounds like a fine idea from the point of view of flexibility. But as far
>> as faster... I guess it depends on how often HeapTupleSatisfiesVisibility is
>> used in contexts where the compile
On Sat, Mar 24, 2007 at 09:37:07PM +, Gregory Stark wrote:
> It sounds like a fine idea from the point of view of flexibility. But as far
> as faster... I guess it depends on how often HeapTupleSatisfiesVisibility is
> used in contexts where the compiler is able to optimize away the conditional
> HeapTupleSatisfiesVisibility reduces to something like
>
> ((*(snapshot)->satisfies) ((tuple)->t_data, snapshot, buffer))
>
> which ought to be faster than it is now.
It sounds like a fine idea from the point of view of flexibility. But as far
as faster... I guess it depends on how often
Martijn van Oosterhout writes:
> On Sat, Mar 24, 2007 at 02:00:30PM -0400, Tom Lane wrote:
>> HeapTupleSatisfiesVisibility reduces to something like
>> ((*(snapshot)->satisfies) ((tuple)->t_data, snapshot, buffer))
> Sounds like a winner. Essentially snapshots becomes objects that have
> methods
On Sat, Mar 24, 2007 at 02:00:30PM -0400, Tom Lane wrote:
> I had an idea about how to make this cleaner and faster at
> the same time. Make all snapshots be real pointers to
> SnapshotData structures (except InvalidSnapshot, which remains
> an alias for NULL). Add a struct field that is a pointe
I've always been annoyed by the implementation of
HeapTupleSatisfiesVisibility (in src/include/utils/tqual.h):
the normal case of an MVCC snapshot is the last one handled,
and we can't expand the set of special cases without slowing
it down even more. Also, as noted in tqual.h, the way we
represen
10 matches
Mail list logo
