Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
pgaddict
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
29 ms
·
301.
▲
by
pgaddict
10y ago
The comment above, which you're referring to, starts with this: > Source is a basic understanding of containers and a basic understanding of databases. > > a) Docker and other container systems are still very young. ... So it&
302.
▲
by
pgaddict
10y ago
AFAIK there's no explicit limit per se - the BDR developers tested it with 48 nodes, but it will work with more nodes. But there are things you'll probably run into - for example this only supports full mesh topology, i.e. each no
303.
▲
by
pgaddict
10y ago
Well, if you're looking for a solution where the whole cluster is perfectly/strongly consistent, then BDR is not for you I guess. What BDR gives you is a guarantee that the changes are applied atomically (i.e. matching transaction
304.
▲
by
pgaddict
10y ago
What do you mean by "got out of sync"? That's a fairly strange issue with physical streaming replication.
305.
▲
by
pgaddict
10y ago
Something like that is possible by using UDR (think BDR but only in one direction): https://wiki.postgresql.org/images/a/a8/Udr-pgconf.pdf
306.
▲
by
pgaddict
10y ago
Those are solutions for very different types of deployments. BDR is asynchronous multi-master, without global transaction management etc. XL is a distributed database with global transaction management, strong consistency, etc. Say you have
307.
▲
by
pgaddict
10y ago
Well, we're also Postgres-XL contributors, so ... ;-)
308.
▲
by
pgaddict
10y ago
XL has a global transaction manager, keeping the whole cluster consistent as a whole, and allows you to query the whole database for analytics, etc. BDR on the other hand doesn't have such global component, so each node is consistent o
309.
▲
by
pgaddict
10y ago
Because there are many different implementations, with different trade-offs and design decisions. Also, the implementation-specific documentation is typically kept fairly close to the code, as the docs need to be kept in sync. So for exampl
310.
▲
by
pgaddict
10y ago
Well, it depends on what you mean by "implementing". I believe we can get the code working in a few days, and there are probably people already working on a PoC of this (or one of the alternative proposals). So if this is what you
311.
▲
by
pgaddict
10y ago
That paragraph might be clearer, but Simon is referring to supporting logical replication from 9.1 to recent releases, which essentially means backporting logical decoding (added in 9.4) back to 9.1. There's no way this could get to of
312.
▲
by
pgaddict
10y ago
Whole 8MB of RAM? Wow! ;-)
313.
▲
by
pgaddict
10y ago
Exactly this is why I still keep my T420s. Also, the new lenovos tend to have absolutely terrible touchpads that move (tilt instead of having proper buttons) etc.
314.
▲
by
pgaddict
10y ago
Yeah, Purism is not very good in communication with customers. Not sure about Librem 13, but my Librem 15 shipped >1 year after the date initially listed on kickstarter. BTW it's July 18, not mid-august (unless you're in a very
315.
▲
by
pgaddict
10y ago
I'm a big fan of attempts to develop free hardware, despite the higher price and other problems (serviceability etc.). But I really hope they'll make a better job with the kill switches than on the Librem laptop. Firstly there are
316.
▲
by
pgaddict
10y ago
Quoting from the very first paragraph of the blog post: > Specifically, if a document is updated while the query is running, MongoDB may not return it from the query — even if it matches both before and after the update! How's that
317.
▲
by
pgaddict
10y ago
FWIW this uncertainty in fsync behavior is essentially the cause of the recent PostgreSQL bug on ext4 (fixed in the last round of minor releases). Basically, on XFS and all other tested filesystems is seems to work just fine, on EXT4 we may
318.
▲
by
pgaddict
11y ago
We do provide PostgreSQL support/DBA for a lot of customers, and while I don't have any detailed stats I probably can make some general conclusions ... I'd say that for most deployments bloat it's not a big issue. But of
319.
▲
by
pgaddict
11y ago
I'm not sure "efficiency" is the right term here. My understanding is that to get "more efficient" execution, you'd have to perform better with the same amount of resources. But parallelism allows using more re
320.
▲
by
pgaddict
11y ago
While I do work for 2ndQuadrant and think that David did a very fine job on this great patch, it'd be a bit unfair not to mention this patch stands on parallel infrastructure built by EDB (and Robert Haas & Amit Kapila in particula
321.
▲
by
pgaddict
11y ago
Because in the PostgreSQL world those are actually major versions, not "point updates" ;-)
322.
▲
by
pgaddict
11y ago
David Dowley (one of the authors of the patch) posted some measurements on TPC-H Q1: https://news.ycombinator.com/item?id=11332713 The machine has 4x E5-4620, so 32 physical cores. And with 30 workers it gets ~80% of the th
323.
▲
PostgreSQL Gets Parallel Aggregate / Benchmark
(blog.2ndquadrant.com)
4 points
by
pgaddict
11y ago
|
0 comments
324.
▲
by
pgaddict
11y ago
FWIW, a simple benchmark by David Rowley (one of the authors of the patch) are here: http://blog.2ndquadrant.com/parallel-aggregate/
325.
▲
by
pgaddict
11y ago
That's not about parallel aggregate but about parallel scan. Also, Robert is not the author of the patch, he did a review and committed it. The actual author are listed in the commit message: David Rowley and Haribabu Kommi.
326.
▲
by
pgaddict
11y ago
It's also a bit frustrating. I'm a shitty developer and it takes ages to get my patches in ;-)
327.
▲
by
pgaddict
11y ago
It also doesn't work because a patch if sometimes reworked by multiple people - either the committer himself, or a co-author of the patch series.
328.
▲
by
pgaddict
11y ago
While Robert certainly does a huge amount of work, this is a bit incorrect perception of how contributing to PostgreSQL works. There are ~20 developers responsible for final reviews and committing changes coming from other contributors, and
329.
▲
by
pgaddict
11y ago
Yep, I agree with that. The problem is we currently have an implementation that behaves as explained above (planned in isolation, evaluated once), and there are applications relying on that behaviour. We can't just change that without
330.
▲
by
pgaddict
11y ago
Because CTEs are not named subqueries, really. For example, CTE is only evaluated once, even if it's referenced in multiple places, and those places may have conflicting ideas of what's the best way to evaluate it. Consider for ex
More ›