On Thu, Mar 30, 2017 at 5:55 PM, Pavan Deolasee <pavan.deola...@gmail.com> wrote: > > On Thu, Mar 30, 2017 at 5:27 PM, Amit Kapila <amit.kapil...@gmail.com> > 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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
