On Wed, Aug 31, 2016 at 3:01 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Uh, not as subtly as all that, because "select * from sequence" will > now return a different set of columns, which will flat out break a > lot of clients that use that method to get sequence properties.
So? Clients expect changes like this between major releases surely. Subtle changes that cause silent breakage for end-users seems scarier than unsubtle breakage that tool authors can fix. On Wed, Aug 31, 2016 at 7:30 PM, Andres Freund <and...@anarazel.de> wrote: > Isn't that *precisely* when it's going to matter? If you have 5 active > tables & sequences where the latter previously used independent locks, > and they'd now be contending on a single lock. If you have hundreds of > thousands of active sequences, I doubt individual page locks would > become a point of contention. I think even two sequences could be a point of contention if you, for example, are using COPY to load data into two otherwise completely independent tables in two separate processes. But that just means the row needs to be padded out to a cache line, no? Or was the concern about things like trying to pin the same page, parse the same page header, follow nearby line pointers...? I'm not sure how effective all that caching is today but it doesn't seem impossible to imagine getting that all optimized away. -- greg -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers