Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Features Coming in PostgreSQL 10

rhaas.blogspot.com

Post reply on HN
Print view View original

1–10 of 138 posts

Re: New Features Coming in PostgreSQL 10

#4

Post by Normal_gaussian »

Extended Statistics! I was following the replication changes, but have just discovered the extended statistics and am more excited about them.

The directory renaming at the bottom of the post is interesting - I wonder if many other projects have to do things like this?

Re: New Features Coming in PostgreSQL 10

#6

Post by avar »

This bit about ICU support v.s. glibc:

    > [...] Furthermore, at least on Red Hat, glibc regularly whacks
    > around the behavior of OS-native collations in minor releases,
    > which effectively corrupts PostgreSQL's indexes, since the index
    > order might no longer match the (revised) collation order.  To
    > me, changing the behavior of a widely-used system call in a
    > maintenance release seems about as friendly as locking a family
    > of angry racoons in someone's car, but the glibc maintainers
    > evidently don't agree.
Is a reference to the PostgreSQL devs wanting to make their index order a function of strxfrm() calls and to not have it change when glibc updates, whereas some on the glibc list think it should only be used for feeding it to the likes of strcmp() in the same process:

    > The only thing that matters about strxfrm output is its strcmp
    > ordering.  If that changes, it's either a bug fix or a bug
    > (either in the code or in the locale data).  If the string
    > contents change but the ordering doesn't, then it's an
    > implementation detail that is allowed to change.
-- https://sourceware.org/ml/libc-alpha/2015-09/msg00197.html

Re: New Features Coming in PostgreSQL 10

#7

Post by JoachimSchipper »

Normal_gaussian wrote: post #4

Extended Statistics! I was following the replication changes, but have just discovered the extended statistics and am more excited about them. The directory renaming at the bottom of the post is interesting - I wonder if many other projects have to do things like this?

Having good directory names helps a lot; I'd be very surprised if other projects didn't also need to make it clear to admins what's happening.

(On the other hand, some projects need to make things _less_ clear - https://github.com/mackyle/sqlite/blob/3cf493d4018042c70a4db... - "users would (...) call [the developers] to wake them up at night and complain".)

Re: New Features Coming in PostgreSQL 10

#8

Post by elvinyung »

Dumb question: does declarative partitioning pave the way for native sharding in Postgres? I'm not super super familiar, but it seems like along with some other features coming in Postgres 10, like parallel queries and logical replication, that this is eventually the goal.

Re: New Features Coming in PostgreSQL 10

#9

Post by JoachimSchipper »

avar wrote: post #6

This bit about ICU support v.s. glibc: > [...] Furthermore, at least on Red Hat, glibc regularly whacks > around the behavior of OS-native collations in minor releases, > which effectively corrupts PostgreSQL's indexes, since the index > order might no longer match the (revised) collation order. To > me, changing the behavior of a widely-used system call in a > maintenance release seems about as friendly as locking a…

Florian Weimer's reply is also interesting:

"Why do you think that? I don't see this documented anywhere, and I doubt it is something many readers of the C standard, the man page, or the glibc manual would expect.

The manual suggests to store the strxfrm output and use it for sorting. I expect that some applications put it into on-disk database indexes as a result. This will lead to subtle breakage on glibc updates.

(The larger problem is that there are definitely databases out there which use B-tree indexes in locale collation order, which break in even more subtle ways if we make minor changes to the collation order.)"

Post reply on HN