21–30 of 44 posts
Earlier quoted context omitted.
Citus should already be saturating i/o during a scan unless you're only hitting one shard. What am I missing about your use case?
Doesn't this inherently depend on the query? Shard-local i/o saturation affects the latency of the entire query if you're not expecting the i/o to the client to saturate.
Besides parallel queries (specifically parallel index scans), the Postgres 10 feature I'm most looking forward to is the work Andres Freund has done on using LLVM to JIT compile expressions[0]. Based on the the layout of the database I work on[1], an insane amount of CPU goes to processing of partial index predicates. If the improvements are anywhere near what is being described in the mailing list, we're going to st…
It should be interesting, but LLVM jit brings in a substantial up front cost. Maybe Andres found a way to mitigate it.
Additionally, at a later stage, caching of compiled programs will play a role, to reduce the frequency of llvm invocation.
The relationship between EnterpriseDB and the at-large Postgres community has always intrigued me. Why do they turn over to the community what they could make part of their proprietary fork? Maybe they make a lot of money consulting and not just licenses and general at-large adoption is good for that side of business.
Earlier quoted context omitted.
Logical replication doesn't matter as much to us. We are using CitusDB (in other words sharded Postgres), and we have our own code for handling replication.
Citus should already be saturating i/o during a scan unless you're only hitting one shard. What am I missing about your use case?
The relationship between EnterpriseDB and the at-large Postgres community has always intrigued me. Why do they turn over to the community what they could make part of their proprietary fork? Maybe they make a lot of money consulting and not just licenses and general at-large adoption is good for that side of business.
Earlier quoted context omitted.
Logical replication doesn't matter as much to us. We are using CitusDB (in other words sharded Postgres), and we have our own code for handling replication.
Citus should already be saturating i/o during a scan unless you're only hitting one shard. What am I missing about your use case?
Besides parallel queries (specifically parallel index scans), the Postgres 10 feature I'm most looking forward to is the work Andres Freund has done on using LLVM to JIT compile expressions[0]. Based on the the layout of the database I work on[1], an insane amount of CPU goes to processing of partial index predicates. If the improvements are anywhere near what is being described in the mailing list, we're going to st…
Re prefetching: PG does that for bitmap index scans, if you enable effective_io_concurrency > 1.
Earlier quoted context omitted.
will oracle be around in 10-20 years? will red hat? which will experience growth?
All things being equal it would take red hat ~30 quarters to make 2bn dollars, or roughly 7 years. 7 years to make what Oracle makes in a quarter. I don't really have a dog in this fight but just FYI I think you missed ops point.