4 ms·

The abstraction is already heavily leaking. It's trivial to patch this claimed abstraction leakage and it won't be worse than the way PostgreSQL already often e

The abstraction is already heavily leaking. It's trivial to patch this claimed abstraction leakage and it won't be worse than the way PostgreSQL already often exclusive-locks whole tables when you add a column and can only statically know the position of columns appearing before a variable-sized one.

valenterry 4y ago
Either every abstraction is leaky (so we can just replace "leaky abstraction" with "abstraction") - or only some abstraction is leaky, then please explain where the current abstraction gives any guarantees of performance that are violated.
- ghusbands 4y ago
  I didn't introduce the claim of leaky abstractions. The context is that the 'new' abstraction is claimed to be leaky by not providing particular performance guarantees. I pointed out that the 'old' one is just as (or more) leaky by that (or most any) definition. If you want me to cite some guarantee for the old one, you should first cite the guarantee for the new one. What people have issue with is the effect column ordering has on the performance of fetching a fixed-size column from a loaded row and on the size of a row. Those are not necessary features and a better design at the start would have avoided it.
  - valenterry 4y ago
    > I didn't introduce the claim of leaky abstractions But you used the term as well - I disagree with both you and the OP on if this case should be called "leaky abstraction". > The context is that the 'new' abstraction is claimed to be leaky by not providing particular performance guarantees That's not a useful definition of "leaky abstraction" by any means. Who decides if "particular performance guarantees" have been provided or not?
    - ghusbands 4y ago
      I agree that it's not a good term. Also, you're confusing your posters - "abstraction now leaks" was introduced by someone opposing the optimization (dymk), not the OP (londons_explore, who used "insufficient abstraction"). And when I used it I intentionally paraquoted as "claimed abstraction leakage", due to the leaky terminology.
      - valenterry 4y ago
        Fair enough. :)

valenterry 4y ago

Either every abstraction is leaky (so we can just replace "leaky abstraction" with "abstraction") - or only some abstraction is leaky, then please explain where the current abstraction gives any guarantees of performance that are violated.

ghusbands 4y ago
I didn't introduce the claim of leaky abstractions. The context is that the 'new' abstraction is claimed to be leaky by not providing particular performance guarantees. I pointed out that the 'old' one is just as (or more) leaky by that (or most any) definition. If you want me to cite some guarantee for the old one, you should first cite the guarantee for the new one. What people have issue with is the effect column ordering has on the performance of fetching a fixed-size column from a loaded row and on the size of a row. Those are not necessary features and a better design at the start would have avoided it.
- valenterry 4y ago
  > I didn't introduce the claim of leaky abstractions But you used the term as well - I disagree with both you and the OP on if this case should be called "leaky abstraction". > The context is that the 'new' abstraction is claimed to be leaky by not providing particular performance guarantees That's not a useful definition of "leaky abstraction" by any means. Who decides if "particular performance guarantees" have been provided or not?
  - ghusbands 4y ago
    I agree that it's not a good term. Also, you're confusing your posters - "abstraction now leaks" was introduced by someone opposing the optimization (dymk), not the OP (londons_explore, who used "insufficient abstraction"). And when I used it I intentionally paraquoted as "claimed abstraction leakage", due to the leaky terminology.
    - valenterry 4y ago
      Fair enough. :)