Re: Hashagg planning bug (8.0.1)

On T, 2005-05-10 at 13:17 -0400, Tom Lane wrote:
> Rod Taylor <pg@rbt.ca> writes:
> > It's the = operator that Slony adds for xxid comparisons. I didn't even
> > think of changes Slony would have made.
> 
> > ssdb=# select * from pg_operator where oid = 716373;
> >  oprname | oprnamespace | oprowner | oprkind | oprcanhash | oprleft | oprright | oprresult | oprcom | oprnegate |
oprlsortop| oprrsortop | oprltcmpop | oprgtcmpop |    oprcode    | oprrest |  oprjoin
 
> >
---------+--------------+----------+---------+------------+---------+----------+-----------+--------+-----------+------------+------------+------------+------------+---------------+---------+-----------
> >  =       |         2200 |      588 | b       | t          |  716353 |   716353 |        16 | 716373 |    716372 |
 716371 |     716371 |     716371 |     716369 | _ssrep.xxideq | eqsel   | eqjoinsel
 
> > (1 row)
> 
> I think you need to have a word with the Slony boys.  They shouldn't be
> marking the operator oprcanhash if they aren't providing a valid hash
> opclass for the datatype.  Per the manual:

Why does slony use its own transaction id type (xxid) in the first
place, why can't we just use standard xid ?

Also, perhaps we could get the getcurrentxid() function accepted in
postgresql core, maybe as pg_get_current_xid(), perhaps together with
pg_oldest_running_xid() and pg_oldest_visible_xid() for determining if
there is any benefit from running vacuum.

I think that knowing current xid is something other applications besides
slony can benefit from.

-- 
Hannu Krosing <hannu@skype.net>