Re: Comparing Datum's at aminsert() stage

From: "Victor Y(dot) Yegorov" <viy(at)mits(dot)lv>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Comparing Datum's at aminsert() stage
Date: 2005-04-19 19:03:19
Message-ID: 20050419190319.GA10376@mits.lv
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [19.04.2005 19:48]:
> That's probably what you *have* to use, since the normal deconstructors
> assume they are working with heap tuples, which are different. But I
> don't understand why you are waiting till after the index tuple is
> formed. The aminsert function gets an array of Datums to start with.
> Why not do it there?

Well, I need that exactly in aminsert.

Each value is stored only once in the index (along with it's own
series-of-bits). Thus, I need to compare each Datum from aminsert()'s
array with the existing ones.

Also, I cannot form tuple the ordinary way (I need all values separated),
so I copy each TuplDesc->attrs[i] into temporary TupleDesc (1 attribute big)
and call heap_fill_tuple(). Actually, I'm not sure this is the right way...

I think, storing some kind of hash-value from the Datum is a good idea, but
it's need to be unique. Is it possible with any existing API?

--

Victor Y. Yegorov

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2005-04-19 19:09:05 Bad n_distinct estimation; hacks suggested?
Previous Message Oleg Bartunov 2005-04-19 18:03:56 Re: Problem with PITR recovery