On Thu, Mar 30, 2017 at 5:55 PM, Pavan Deolasee <[email protected]> wrote: > > On Thu, Mar 30, 2017 at 5:27 PM, Amit Kapila <[email protected]> > wrote: >> >> >> >> How have you verified that? Have you checked that in >> heap_prepare_insert it has called toast_insert_or_update() and then >> returned a tuple different from what the input tup is? Basically, I >> am easily able to see it and even the reason why the heap and index >> tuples will be different. Let me try to explain, >> toast_insert_or_update returns a new tuple which contains compressed >> data and this tuple is inserted in heap where as slot still refers to >> original tuple (uncompressed one) which is passed to heap_insert. >> Now, ExecInsertIndexTuples and the calls under it like FormIndexDatum >> will refer to the tuple in slot which is uncompressed and form the >> values[] using uncompressed value. > > > Ah, yes. You're right. Not sure why I saw things differently. That doesn't > anything though because during recheck we'll get compressed value and not do > anything with it. In the index we already have compressed value and we can > compare them. Even if we decide to decompress everything and do the > comparison, that should be possible. >
I think we should not consider doing compression and decompression as free at this point in code, because we hold a buffer lock during recheck. Buffer locks are meant for short-term locks (it is even mentioned in storage/buffer/README), doing all the compression/decompression/detoast stuff under these locks doesn't sound advisable to me. It can block many concurrent operations. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
