pgaddict

12 ms·

91.
by pgaddict 6y ago
Yeah, that's true. That being said, there are various other companies providing this type of services around the world, although most of them are more local (but hey, anyone can be global with a zoom meeting now). There are also quite
92.
by pgaddict 6y ago
I have no idea what options are being considered by the core team, but I'd imagine the most likely one is replacing one of the people now working for EDB with someone else.
93.
by pgaddict 6y ago
I doubt that's possible, for a number of reasons. 1) Neither company owns any part of the PostgreSQL code / docs. We do have various proprietary tools, of course, but so do other companies. 2) The companies employ quite a few Post
94.
by pgaddict 6y ago
Interesting question. Considering how different the gid and btree indexes are, I'd say it's very different. GIN essentially builds a posting list for each value in the column, and compresses that (which might be seen as a kind of
95.
by pgaddict 6y ago
I'd say some of the limitations hit by Uber were real, and were a bit of a PITA even before that. Some were improved significantly since then, others still need to be considered when designing application accessing PostgreSQL. I'd
96.
by pgaddict 6y ago
I haven't down-voted the post, but I'd say it's a bit misleading. Firstly, it's not quite true "Uber migrated away because of write amplification" because they named multiple other reasons contributing to that
97.
by pgaddict 6y ago
There was a long discussion about multiple patches that "almost made it" on an internal release list. Ultimately, the conclusion was not to push them after the code freeze date (which was already extended by a week). Obviously, it
98.
by pgaddict 6y ago
Ideally thousands (and maybe even tens of thousands) of connections. At the moment we're quite far from that, as the benchmarks in the thread [1] demonstrate (low hundreds, I'd say). There's an awful lot of applications desig
99.
by pgaddict 7y ago
Sure the primary concern for Apple is users. But it's not like the platform could exist without the ecosystem around it, which largely depends on developers publishing apps. And it's not as if the dev accounts are not subscription
100.
by pgaddict 7y ago
Don't forget waffles!
101.
by pgaddict 7y ago
Right, that's about the right ballpark - tens of second for unplanned events (failover), a couple of seconds for planned events (switchover). We can have a lenghty discussion about all the caveats and options, but in my experience tryi
102.
by pgaddict 7y ago
Depends on packaging. Most distros should have that compiled as a separate package, e.g. postgresql12-llvmjit. So you install that (along with the regular packages) and you'll have JIT.
103.
by pgaddict 7y ago
Not sure what you mean. Previously CTEs were always materialized (i.e. stashed into a buffer, somewhere), in PostgreSQL 12 it's optional and disabled by default for various cases that don't require it. The problem with materializa
104.
by pgaddict 7y ago
No, and I wouldn't hold my breath for that to happen. The trouble with multi-master is that there are way too many possibilities what it might mean - different purposes require different trade-offs, and PostgreSQL is unlikely to commit
105.
by pgaddict 7y ago
Not sure what doesn't add up? While PostgreSQL is certainly around longer than 10 years, the release schedule was somewhat random until ~10 years ago. Since then the project sticks to a yearly schedule, with one major release per year,
106.
by pgaddict 7y ago
Yeah, there was a lengthy discussion about what the default behavior should be during development. Ultimately, inline by default prevailed, and I think it was the right decision. Inlining seems like the right choice for vast majority of cas
107.
by pgaddict 7y ago
That very much depends on the CTE. The release notes say this: > CTEs are automatically inlined if they have no side-effects, are not recursive, and are referenced only once in the query. Inlining can be prevented by specifying MATERIALI
108.
by pgaddict 7y ago
I think it's a bit strange to claim the PostgreSQL community just declined the patch. Just look at the thread on pgsql-hackers list: https://www.postgresql.org/message-id/flat/46ED7555-9383-45D... As anarazel
109.
by pgaddict 7y ago
Linux kernel behavior is still the same. The error reporting issues (failure to report I/O errors in various cases) has been fixed on recent kernels, AFAIK. PostgreSQL now PANICs on I/O errors during fsync, forcing a recovery.
110.
by pgaddict 7y ago
> Every computer component can fail in arbitrary ways, including drives. > > If you’re not robust against that, then when things like fsync fail, then you’ll lose availability and/or data. The fact is that often the I/O i
111.
by pgaddict 7y ago
> It is broken but there's no behavior that isn't, and the Postgres developers quickly understood why changing Linux's behavior isn't really possible. I think there's still a fair number of PostgreSQL developers
112.
by pgaddict 7y ago
Can you provide a link to that recommendation? There's pretty much no difference between those types, they are all stored exactly the same way. Varchar has a bit of extra cost for the length check, but that's OK when you want to e
113.
by pgaddict 7y ago
Well, any camera can photograph from any distance ...
114.
by pgaddict 7y ago
You're missing the point. COPY TO/FROM PROGRAM is useful e.g. when you already have the data locally on the server (same filesystem, ...). COPY FROM STDIN/STDOUT are useful when the data are on some other system (s
115.
by pgaddict 7y ago
Yeah, and it's super-useful in some cases. Say, passing data directly to gzip (or reading it from it).
116.
by pgaddict 8y ago
Except that this issue (both the behavior and lack of exact docs) applies to other kernels, not just Linux. See https://wiki.postgresql.org/wiki/Fsync_Errors So no, this is not just about Linux.
117.
by pgaddict 8y ago
nitpick: BGWrites is not involved in checkpoint - it's a separate process, doing something like checkpoint (so an alternative).
118.
by pgaddict 8y ago
Right, this is about "ephemeral" failures which are becoming more common thanks to accessing storage over network, virtualization, thin provisioning etc.
119.
by pgaddict 8y ago
The difference is that with the fix, PostgreSQL should not silently lose data (confirmed transactions). What was possible before is: 1) transaction committed OK (which involves fsync of WAL, but that's it) 2) during checkpoint (essenti
120.
by pgaddict 8y ago
No one suggested having an anonymous account is an issue. The issue is the account being a sockpuppet one.

More ›