On Mon, May 15, 2017 at 5:28 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, May 12, 2017 at 3:07 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> I agree with you that it might not be straightforward to make it work, >> but now that earliest it can go is v11, do we want to try doing >> something other than just documenting it. What I could read from this >> e-mail thread is that you are intending towards just documenting it >> for the first cut of this feature. However, both Greg and Simon are of >> opinion that we should do something about this and even patch Author >> (Amit Khandekar) has shown some inclination to do something about this >> point (return error to the user in some way), so I think we can't >> ignore this point. >> >> I think now that we have some more time, it is better to try something >> based on a couple of ideas floating in this thread to address this >> point and see if we can come up with something doable without a big >> architecture change. >> >> What is your take on this point now? > > I still don't think it's worth spending a bit on this, especially not > with WARM probably gobbling up multiple bits. Reclaiming the bits > seems like a good idea, but spending one on this still seems to me > like it's probably not the best use of our increasingly-limited supply > of infomask bits. >
I think we can do this even without using an additional infomask bit. As suggested by Greg up thread, we can set InvalidBlockId in ctid to indicate such an update. > Now, Simon and Greg may still feel otherwise, of > course. > > I could get behind providing an option to turn this behavior on and > off at the level of the partitioned table. > Sure that sounds like a viable option and we can set the default value as false. However, it might be better if we can detect the same internally without big changes. -- 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
