pgaddict

26 ms·

271.
by pgaddict 10y ago
I am pretty sure. Let me quote the official docs from https://www.postgresql.org/docs/9.6/static/runtime-config-au... : =========================================================== autovacuum_vacuum_cost_limit
272.
by pgaddict 10y ago
I don't understand what problem you have with the combination of threshold + scaling factor (and what would be a better solution). There are no perfect default values for those parameters, as it really depends on workload patterns. The
273.
by pgaddict 10y ago
I find the recommendation to leave the cost limit alone strange. The problem is this is a global limit, shared by all autovacuum workers. The default (200) means all workers combined should not do more than 8 MB/s reads or 4 MB/s
274.
by pgaddict 10y ago
I suspect there was a secret meeting where all the manufacturers discussed ways to make the users suffer, and adding the numpads was #1 on their list. The only two vendors absent on that meeting were Apple and Dell, but Dell then attended t
275.
by pgaddict 10y ago
I wonder whether they'll offer a version without a discrete GPU, and how difficult will it be to install/run Linux on it ... I've been looking for a good 15" laptop laptop for some time, and all other manufacturers only
276.
by pgaddict 10y ago
No one implemented a better solution ;-) Jokes aside, it seems simple but is fairly tricky, as it depends both on input data and various other parameters. For example for array_agg() or string_agg() it might be estimated from number of entr
277.
by pgaddict 10y ago
A few comments regarding the count_distinct extension (author here): > Note that custom extensions written in C like count_distinct are not bound by the value of work_mem. The array constructed in this extension can exceed your memory ex
278.
by pgaddict 10y ago
Right, I was going to point out that one of the main issues with the per-table tally (trigger-based) is limited concurrency, as all inserts/deletes have to modify the same row. Deadlocks (due to updating counters for different tables)
279.
by pgaddict 10y ago
> Granted, it’s possible to shoehorn similar functionality on top of CouchDB, Mongo or PostGres - but RethinkDB ... PostGres does not exist. Correct spellings are Postgres and PostgreSQL.
280.
by pgaddict 10y ago
There are row stores (e.g. Oracle does that) that reorganize the page structure from row to column, usually achieving significantly better compression ratio without significant impact on OLTP performance.
281.
by pgaddict 10y ago
Well, that really depends on where exactly you place start of a year ;-) Chinese New Year was February 8, 2016. Orthodox New Year was January 14, 2016. So it's 2:1 for me.
282.
by pgaddict 10y ago
There's still only one major PostgreSQL release per year. There were a few posts about cool stuff built on top of PostgreSQL, a few posts about progress of the 9.6 development (e.g. when the parallel query got committed) etc.
283.
by pgaddict 10y ago
Definitely, memory is probably the most important resource when running Qubes. My T420s has 8GB and it's just enough, I wouldn't go for less than 16GB in the next laptop.
284.
by pgaddict 10y ago
IMHO if you need to move stuff between appvms often, that suggests the compartments are inappropriate and you should rethink them.
285.
by pgaddict 10y ago
Thanks, it's nice to see the patch is likely beneficial for other people!
286.
by pgaddict 10y ago
That is far too optimistic, IMHO. FDW are a great way to access external data sources, but it lacks proper support for visibility and transactions, and so on. Also, the FDW API follows the "tuple at a time" execution model, which
287.
by pgaddict 10y ago
Or design the application so that there are no conflicts (e.g. modifying different subsets of users on different nodes).
288.
by pgaddict 10y ago
I'm using Qubes/Xfce for quite a long time (since R2, I think, so >2 years) on all my devices (T420s, Gigabyte BRIX workstation and a few other devices). I'm quite happy with how it works - it's a bit less convenient
289.
by pgaddict 10y ago
The nodes don't need to be up 100% of the time. Thanks to replication slots, the WAL on the other nodes will be kept until the node connects again and catches up. So it really depends on how much disk space you have on the other nodes.
290.
by pgaddict 10y ago
Not exactly. It means that enough infrastructure was moved into PostgreSQL 9.6, making it possible to run BDR on unmodified PostgreSQL. Before 9.6 it was necessary to use patched PostgreSQL packages.
291.
by pgaddict 10y ago
Yes, it means it was tested with up to 48 nodes. There's no hard limit on the number of nodes, but at the moment BDR uses full mesh topology (each node has connections to all other nodes), which becomes an issue as the number of nodes
292.
by pgaddict 10y ago
The answer really depends on what you mean by "multi-master" - particularly whether you're looking for synchronous or asynchronous solution, what consistency model you need (strongly consistent cluster or nodes consistent ind
293.
by pgaddict 10y ago
It's quite difficult (or impossible) to get a single "right" value, as it depends both on the workload and hardware (say, whether you have SSDs attached directly or through a RAID controller).
294.
by pgaddict 10y ago
Extremely dependent on hardware (and queries, as it only affects Bitmap Index Scans).
295.
by pgaddict 10y ago
It's somewhat related to the number of data drives, but as you point out it's a bit more complicated in practice - it's not just the number of drives. For example due to parallelism built into SSDs (each SSD is actually a sta
296.
by pgaddict 10y ago
And why is this a headache? Every time a new feature is introduced, you have to worry about the PostgreSQL version. If you're developing an application in-house, this is not a big deal - you can make sure you have the right PostgreSQL
297.
by pgaddict 10y ago
Absolutely agree. Pulling the rug is a powerful incentive both for the customers and the CAs. Customers will have to consider the likelihood the CA will be revoked due to poor security practices, CAs will have to show that they're not
298.
by pgaddict 10y ago
You're right there's definitely some inter-backend caching effects, no doubt about that. Still, the common recommendation to set e_c_s to 75% of RAM is a bit excessive (although it's true the blog post does not mention any pa
299.
by pgaddict 10y ago
Well, I'm a bit drunk at the moment, but I'll try explaining anyway ... The documentation says this about effective_cache_size [ https://www.postgresql.org/docs/9.5/static/runtime-config-qu... ]: Sets
300.
by pgaddict 10y ago
It's not the only section that's incorrect. The effective_cache_size is wrong too, shared_buffers is misleading (e.g. new PostgreSQL versions are not subject to SysV kernel limits), and so on. The recommendation to set low checkpo

More ›