this is good for a few servers - but its sequential nature will become onerous if for example you needed to run something that took 10 minutes on 100 hosts.
ansible ad-hoc commands do almost exactly what you do but in a more scalable fashion
This is not transactional. What happens when a host reboots randomly in the middle of execution? Or the network drops? You're stuck looking through the logs to see the failure along the way. No thanks. I want something that forces me to be idempotent and retries automatically on failures.
I have my files pseudo-organized, meaning I kind of try to keep them where they should be logically, but since this varies a lot - they're not really organized.
The thing is - I use "everything" a free instant file search tool from voidtools.
It is blazingly fast, just start typing and it finds files while you type.
It uses the ntfs file system (windows only, sorry everyone else) existing index to perform instant searches, it is hands down the ultimate most fast file search tool I have ever encountered - files literally are found while you type their names, without waiting for even a milli second.
So, no organization (the ocd part of me hates this) but i always find my files in an instant, no matter where i left them.
I don't get it?
Table partition is already supported in PostgreSQL now and has been for a long time now (at least since 8.1);
Where I work we utilize table partitioning with PostgreSQL 9.4 on the product we're developing.
As far as I understand, this is about declarative partioning. So you don't have to implement all the details yourself anymore, you just declare how a table should be partioned instead of defining tables, triggers, ...
Note that there is no shorthand syntax (yet), where you define a partitioned schema in just one line of DDL.
As of now, you still need to create the root partitioned table as one command specifying the partitioning method (list or range), partitioning columns (aka PARTITION BY LIST | RANGE (<columns>)) and then a command for every partition specifying the partition bounds. No triggers or CHECK constraints anymore though. Why that way? Because we then don't have to assume any particular use case, for which to provide a shorthand syntax -- like fixed width/interval range partitions, etc.
That said, having the syntax described at the beginning of the last paragraph in the initial version does not preclude offering a shorthand syntax in later releases, as, and if we figure out that offering some such syntax for more common use cases is useful after all.
The linked patch notes specifically mention the difference between this and table inheritance based partitioning.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations.
"Supported" in so far as you could basically roll your own implementation, having it managed by the engine is massively more useful and easier to support and setup. A lot of things are supported if you're willing to bodge it together like that.
It sounds like this is column level partitioning.Each column or columns (based on partitioning expression) is stored as different subtable (or something similar) on disk.If only few columns are frequently accessed, they can be put on cache/faster disk or other neat optimizations for join processing.
Maybe I don't get you, but i don't think so, PostgreSQL is not a columnar database.
If i got this patch right, each partitioned table will have the same data structure and store whole rows (it's even more restrictive than previous inheritance mechanism that allowed extending by adding additional columns).
Column or expression should only define in which table an inserted row is supposed to be stored. A single row will never been torn apart. Still it look like a foundation that facilitate sharding BigData(Set) between multiple servers when used in conjunction with foreign data. However a lot of performance improvements will still be needed to compete against solid NoSQL projects (in which you really have a BigData use case).
But looking a bit forward, developing performances improvements on top of an ACID compliant distributed database seems less difficult than to develop a NoSQL project for it to become ACID.
It is not. The partitions are by row. The novelty is in that it is truly native support, rather than a couple optimizations to make roll-your-own palatable.
It's on the roadmap, but there would be a ton of API calls to make; one of the main features is the ease of rescheduling things. Also, the idea is you can spread your task out over a day, because it's mainly a plannable timer, so any calendar integration would just be in the "day" field.
