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
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 |