I think two things are being confounded here: (1) places most likely to contain people with COVID; and (2) places most likely enable COVID to infect someone.
Many people go to supermarkets; they’re like central hubs in a network. It doesn’t mean that as much transmission happen there as in smaller confined places like houses and bars.
Hi, one of the creators of IOx here. Unlike InfluxDB where you can only do efficient range based queries on one time value, in IOx you will be able to apply predicates efficiently to any column. That means you can have several columns for different times (e.g., time created, forecast time, expire time..).
You will be able to do efficient range queries on any of these. Most use-cases will work best when you partition your data into time chunks, which commonly would be the time you inserted the samples into the database (created time in your case I guess).
The £30 Apple Pay limit in the UK is becoming less of a thing. In major retailers that accept Apple Pay I have used my phone to pay for items into the hundreds of pounds without issue.
In the last few months we have made quite a few improvements to data storage and indexing. Features that are available by default in 2.0, which are significant changes from releases earlier than, say, 1.6 include:
- Significant TSM encoding and decoding performance improvements.
- The TSI index will be on by default.
- Queries that use the same tag key/value filters will be answered from the index more quickly using an LRU cache.
- Field keys will now be indexed in 2.0, making filtering/grouping on field keys more efficient.
- Improvements to how series are extracted from the index, and points data from the TSM engine, which helps with memory performance for queries.
- Significant performance improvements to measurement deletion.
> And can data points be incremented instead of the current field-replacement crap when you get new points with the same tag set?
I want to use influx to store _statistics_ not _events_. Basically, my data points are tag-sets and counts.
There are several ways to achieve this; for example, you can send the events to influx and have continuous queries to gather the statistics. That doesn't work well when you have a lot of events, and where they arrive out of order and at high latency, etc.
So what you typically end up having to build is a stats thing that sits in front of influx and tracks the counts of events with particular tag sets in particular time buckets, and then keep uploading these to influx.
And there are two ways to do that:
1) you are not stateful and you keep uploading deltas and incrementing the nanoseconds to avoid data-point collision; you can then get the data out of influx with sum() on the fields and grouping by whatever the time bucket is. I tried this and influx grinds to a halt eventually.
2) you are stateful and track the totals outside influx, and keep uploading a newly-written data-point to overwrite the fields for that bucket in influx. This is much less data in influx and much easier to query, avoiding sum() etc. Its like I end up with something in front of influx doing what I want influx to do.
What would greatly simplify life is if the line format which looks like this:
and in the second case, where the line is prefixed with a + sign, influx knows to add the fields if the data-point collides with another rather than overwrite them.
This would mean that people trying to store statistics in influx could add to those statistics statelessly. A massive simplification.
I've had other problems, like I have way more than 1M series. Its painful. My influx boxes hit iowait far too often, which is weird because the boxes have more RAM than the total dataset.
Hi, I'm one of the engineers working on the storage side of InfluxDB. Improving the performance of adhoc deletes, as well as import/export (backup/restore) are features that my team will be actively working on in the coming weeks and months.
I don't live in Sweden so I can't claim to be an expert (I like in the UK), but I find it highly unlikely that your claim of a 61% tax rate in Sweden is correct. It's likely the highest tax rate possible (in the UK that's 45%).
If you look at a tax calculator you will see that for a Swedish salary equivalent to $60K, the effective tax rate is actually ~27%.
$60K USD == ~540K SEK, which is 45K SEK a month.
Plugging 45,000 into [1] and choosing the municipality of Stockholm results in a net monthly income of 32,587 SEK.
Well, first you have to calculate that the company pays 31.42% of your total salary in payroll taxes. This is illegal to print or show in any way or form to the employee from the employer.
Then on most goods there is a 25% tax, additional taxes other categories of goods such as gas, cars, alcohol and so forth.
So if the company pays you 60k SEK, you'll see ~45k on your payroll slip. The 61% percentage is the average total tax burden on a individual from all of these taxes.
Payroll tax is not your salary - it's tax on their employment of you, of an amount due that's proportional to your salary. It's the company's money, not yours.
(Would they pay you more if that tax wasn't due? Well, possibly, I suppose. Or they might just pay you the same, and then buy more stuff, employ more people, pay the company owners more money, that sort of thing.)
What are you smoking? Change it, it is bad for logic: any tax a company pays for you is from the money you bring in, not from the shareholders personal bank accounts. Nobody pays for the pleasure to have someone as an employee, but for the employee to deliver more than what is paid, otherwise you go under.
Reduce the payroll tax, and, what then? Same amount of money coming in, same going out on salaries, less going out on payroll tax. Now the business has options. It can buy more stuff; it can employ more people at similar salaries; it can give the owners more money.
But the argument being made appeared to be that it will give its existing employees pay rises, to each one in line with how much payroll tax it was paying for each of them previously - but this just strikes me as a bit unlikely.
In Romania by law the company contribution was included in the payroll; there was no change in salaries, but people were finally able to see the total taxes they paid and calculate the percentage correctly: it was about double vs what they thought.
The 61% number in this case came from the top marginal tax rate on income in Sweden. The fact that it's roughly the same is payroll + income tax is a coincidence.
