anarazel

87 ms·

871.
by anarazel 8y ago
> PostgreSQL is amazing, but there isn't a company behind it, There are several companies behind it, and most of them are looking for people. > and 2ndQuadrant will probably only hire you to work on it if you're already a co
872.
by anarazel 8y ago
> The risk of crypto currencies is too high > More likely they are afraid that it will be a high cost for them with very little reward. That, that, that is the same thing.
873.
by anarazel 8y ago
> Can you request multiple heterogeneous result-sets from PG now, with something that looks like a stored procedure? Not prettily. You can return cursors, you can use json etc, ... But you can pipeline SQL statements. I.e. just send N S
874.
by anarazel 8y ago
> The main place where LLVM bites you is compatibility. There simply is none. This is a constaint drain on your resources and a lot of projects can't afford to keep up. There is even a project on LLVM's own home page which is w
875.
by anarazel 8y ago
> Can anyone think of any reasonably common stacks using LLVM as a JIT? We just added LLVM based JIT to PostgreSQL. Don't think we have quite the same issues as JITing generic interpreted languages though, because the planner gives
876.
by anarazel 8y ago
That is not a counterpoint in any sort of way to what I was saying. Fear of being controlled could be enough. Thus making the origin point above my post wrong.
877.
by anarazel 8y ago
I don't think that's a claim you can validly make. Perception of how hard it is to get things onto a plane can prevent attacks. And unless you screen everyone's minds, you can't know that that's not the case. I&#x2
878.
by anarazel 8y ago
But you need to prove that it halted - to you manager obviously - that's the impossible and stressful part.
879.
by anarazel 8y ago
> t seems they can JIT the process for creating an index, which has some modest improvements We could, but currently don't yet. Not enough time / too short days...
880.
by anarazel 8y ago
> Woah, the JIT for queries sounds really interesting! Thanks (author here ;)). Note it's currently not the actual queries themselves that get JIT compiled (started to work on that for v12), but evaluation of expressions inside quer
881.
by anarazel 8y ago
> I’d assume that most queries are limited by memory / disk access time That's not true for all that many analytics statements actually. Good storage systems can deliver data quite fast, and in many cases the buffer cache can h
882.
by anarazel 8y ago
> You could get this behaviour in PostgreSQL 10 by creating the column and setting its default in separate DDL statements (all in a single transaction). But that'd mean that the existing columns wouldn't have the DEFAULT value.
883.
by anarazel 8y ago
> so [block,item] is enough, but global indexes will require [partition,block,item]). That's probably the easier bit, I'd guess that adjusting a lot of the relevant in-memory structures to share relations, uniqueness checks acr
884.
by anarazel 8y ago
I suspect we'll want both. The bloom index only helps if you have decent spatial locality. Which you won't for say a serial, uuid, etc. There's also types of indexes where it's probably going to be more efficient to ha
885.
by anarazel 8y ago
It's technically possible to have both global indexes, and constraint checking that just checks every single partition for conflicts. The former isn't trivial to implement in PG (there's a fixed-width scheme for the target t
886.
by anarazel 8y ago
What you're not supposed to allow is letting both succeed, because then the clients would assume everything went fine. If one errored before the commit , both transactions didn't execute successfully and you're fine. Pretty
887.
by anarazel 8y ago
No. ACID doesn't guarantee that you can't have constraint violations triggered by a concurrent session. That'd make any sort of efficient constraint pretty much impossible. It guarantees that that error is caught despite th
888.
by anarazel 8y ago
> And on top of that, in the realm of database engineering, Amazon is absolutely a newcomer, they've got another good 15 years before they can even start to be in contention for "reliable and trustworthy database vendor" T
889.
by anarazel 8y ago
> I haven't tested but I don't think that will happen on the default settings for postgres. I know for a fact that it won't on higher isolation levels. Unfortunately you're wrong. I've now tested it, but I was al
890.
by anarazel 8y ago
> The update isn't inserting anything. Either the row exists already, or it doesn't. Maybe I'm missing something? Rows can exists without you being able to see them. Consider: S1: BEGIN; S2: BEGIN; S1: INSERT name
891.
by anarazel 8y ago
Except that that's not concurrency safe in a transaction, because you might not yet see the row inside the NOT EXISTS() subquery if it hasn't yet committed.
892.
by anarazel 8y ago
> Apparently saying that engineers should be able to handle concurrency errors is controversial? I didn't vote either way. But perhaps it's less the fact that they should be able to handle concurrency, and more that replicating
893.
by anarazel 8y ago
I bet that at least 9/10 experienced engineers in the space will come up with a solution that has at least one of a) incorrect behaviour under concurrency b) unnecessary deadlocks c) extreme slowness d) break w/ triggers, row leve
894.
by anarazel 8y ago
> which if you're a good coder would also involve some try/catch and proper fallback behavior in case of an error It's actually really hard to do so correctly in the face of concurrency. Do not attempt to do so unless y
895.
by anarazel 8y ago
> An unsung virtue of the ad-driven web it's is inclusiveness and strong worldwide redistribution effects. Everybody sees the ads, however the actual value of a pair of eyeballs is widely variable, by orders of magnitude so. It&#x27
896.
by anarazel 8y ago
OTOH there's concurrency and prefetching logic increasing average queue depth.
897.
by anarazel 8y ago
> But you don't get impostor syndrome on PG internals itself do you? I do. > If you do, could you expand on the parts of PG internals that you know the best (I assume that's what you've written/hacked on the most)
898.
by anarazel 8y ago
> I don't think widely considered experts experience the impostor syndrome in the same way that I see it explained. Experts on postgres internals don't wonder if they're experts on postgres internals... Um. I'm an exp
899.
by anarazel 8y ago
> I worry that if the Postgres people do make that change, they'll find themselves hearing from a different set of kernel developers that they should have known direct IO doesn't work properly and they should be using buffered
900.
by anarazel 8y ago
And in v11, even if there's a default column!

More ›