161–170 of 258 posts
Does anyone know if the partitioning can enforce a uniqueness constraint across child tables? I couldn’t tell from the write up if this is one of the things addressed with Native Partitioning
Earlier quoted context omitted.
Parallel query was already there in 9.6 though this release improves on it further.
It makes parallel query much more useful. There were very few places that parallel query helped with my workload in 9.6, that is not true for 10.
Earlier quoted context omitted.
Yes, you have to add the repo, the same as if you wanted the latest postgres bits on any distro. You also have to edit configs for both and you can also choose to install extra tools for both. I'm surprised at how many people seem to have taken issue with a simple comment. Postgres is easy to install... and now so is MSSQL compared to the complex slow GUI installer they had before. Maybe it'll help the original comme…
Debian and derivatives have it in repos by default. Please don't make claims like those.
> I'm surprised at how many people seem to have taken issue with a simple comment.
Does anyone have any use cases where PostgreSQL falls down/loses to other DB systems? I know sharding/replication has long been a sticking point, but what else is there? Why do people still choose MySQL/MariaDB/Oracle over PostgreSQL at all?
Dynamic SQL in Postgres is really frustrating. I understand why. It's because you shouldn't fucking write SQL that writes SQL. On the other hand, sometimes you just have to. SQL Server . . . I won't say it makes it easy, but it doesn't make it so goddam impossible. If I lived in a world without Postgres, I would use SQL Server without thinking twice. MySQL/Maria I'm not fond of, and I kind of don't want to touch them…
PgSQL more and more looks like the "redis of databases". Whatever the problem, you can almost always find a good reason to use it :) You get great performance for the simple "dumb" use case (relational data in DB term, key/value store in redis case), and lots of awesome additional feature on top of it for more complex situations. I love it.
That's like calling Swift "the Ruby of programming languages".
Earlier quoted context omitted.
do you find that it's significantly slower than just using psql?
Yes, in many cases (until I stopped using it), it messed up my benchmarks. I was testing some queries, and often it was: - pgserver fast, returns 10000 rows, pgcli takes time to parse -> result: total time 10s - pgserver slow, returns 1 row, pgcli instant -> result: total time 10 sec. As we are working in efficient C/C++, our internal time to parse the query set is closer to psql than pgcli, so we tend to prefer the…
Earlier quoted context omitted.
are they? even without ssl? by default?
Not sure about SSL, but in the past customers of mine have copy-pasted full Heroku PG URLs to me and I was able to get in via `psql` immediately. So yes they're public but their addresses are basically impossible to guess.
Ipv6 only then?
Earlier quoted context omitted.
For local cluster, try DRBD to replicate at the disk level. The DRBD replication can be synchronous and are very fast. Add Linux-HA for health monitoring and automatic failover. When failed over, the standby machine just starts up PostgreSQL and recovers from the transaction log. Uncommitted transactions on the primary machine that haven't been written to disk and replicated will be lost, which is consistent with the…
I would strongly discourage this kind of solution. DRBD is to replicate disk. As pointed out is not Postgres specific, and it doesn't understand the data it replicates. One of nightmare of replication is that there's latency and data never makes it instantly to the other host. This means that there is a possibility that once the master fails, the database file on the other host might be in a corrupted state. If your…
In case of the secondary not available, the data are queued up in the primary and sync up with the secondary when it comes back online. If the primary's disk is destroyed at that time, the failure case and data loss is the same as the database's native replication.
DRBD is much simpler and less error prone precisely because it does not care to understand the application data. It just deals with disk block. The simplicity also helps performance greatly. Benchmark has shown there's negligible impact when doing synchronous replication.