Tostino

110 ms·

1591.
by Tostino 10y ago
That is really an amazing amount of work that has gone into this next release. This is really getting Postgres up to par with the commercial offerings, and hopefully it keeps progressing for v11. It's especially important now since ser
1592.
PostgreSQL Parallel Query v2(rhaas.blogspot.com)
265 points by Tostino 10y ago|42 comments
1593.
by Tostino 10y ago
I totally agree that arbitrary password rules are not a good thing, they frustrate users to no end, and can make things less secure. I really liked the zxcvbn library from Dropbox, as it allows you to catch those really egregiously bad pass
1594.
by Tostino 10y ago
Not a problem at all if you provision your server properly so you aren't IOPS bound, though there are plenty of databases which simply won't fit on NVMe drives, so in those cases, yes it could still be a problem.
1595.
by Tostino 10y ago
I can see a use case for it, as long as it delivers on performance. No one minds high TDP, as long as it offers a performance advantage. Hell, some servers have 4-8 Titans in them, and no one is complaining about their TDP. If a 260W CPU
1596.
by Tostino 10y ago
Yeah, every single release since then has had work done on scaling Postgres up on a single machine. They have been working on eliminating bottlenecks one after another to allow it to scale on crazy numbers of cores. I've seen benchmar
1597.
by Tostino 10y ago
If you want to use a server side tool, I wrote a port of it in Java (with quite a few extra features): https://github.com/GoSimpleLLC/nbvcxz At least on the server side, size doesn't matter quite as much.
1598.
by Tostino 10y ago
Author here, i'm happy to answer any questions you may have.
1599.
How we handle user password security – GoSimple(gosimple.me)
1 points by Tostino 10y ago|1 comments
1600.
by Tostino 10y ago
Did you compare the execution plans of both queries? Without doing that, it's hard to know why the planner did what it did. Maybe statistics were off and it was choosing a worse plan for the left join because it thought it'd be fa
1601.
by Tostino 10y ago
The last release (1.2.0) introduced a new algorithm to combine the matches found within a password which provided better results, but drastically slowed down estimations. I spent some time profiling where that extra time was going, and opti
1602.
Nbvcxz 1.2.1 released – Now with 10x faster password strength estimations(github.com)
2 points by Tostino 10y ago|1 comments
1603.
by Tostino 10y ago
Interestingly enough, I just recently released a password strength library which can help enforce these exact requirements. https://github.com/GoSimpleLLC/nbvcxz
1604.
Nbvcxz 1.2.0 released: better password strength estimation(github.com)
1 points by Tostino 10y ago|0 comments
1605.
by Tostino 10y ago
Developer here, At my company we needed a Java library that did the same type of work that zxcvbn does, and back in 2014 when I started looking around, I didn't see anything. So I took it upon myself to create a Java implementation of
1606.
Nbvcxz: Password Strength Estimator – Initial Release(github.com)
3 points by Tostino 10y ago|1 comments
1607.
PostgreSQL Primary Key Type Analysis(gosimple.me)
1 points by Tostino 10y ago|0 comments
1608.
by Tostino 10y ago
Not worked with them directly, but have followed the pg-hackers mailing list and they are have a bunch of contributions back to core Postgres, and have some core maintainers on staff. They seem very open with everything they do, as opposed
1609.
by Tostino 10y ago
It actually forks a new process per connection.
1610.
by Tostino 10y ago
Huh, that's funny to see a comment of mine copied word for word from Reddit: https://www.reddit.com/r/programming/comments/4in70l/postgre...