71–80 of 85 posts
Earlier quoted context omitted.
Lack of foreign keys does not effect performance. In fact, having foreign keys is a net-negative performance-wise because it means that each foreign key must be checked for every insert/update/delete.
Errm, we're talking about performance of joins
Earlier quoted context omitted.
Semaphore as a service Slack Chat bot.
Seen that. Shared drive with excel files, people would shout at each other to 'release the lock'
I'm working on migrating an app right now (just one MySQL database) but can highly recommend [pgloader]( http://pgloader.io/ ). It has a bunch of built-in and configurable rules to cast different column types to PostgreSQL and the developer has been very responsive in helping me make weird column types work, too.
We run MySQL on product and am in the process of de-normalizing it. If I have compelling reasons, I might push for migration to Postgres but I never found any genuine reasons. Uber even migrated the opposite way from Postgres to MySQL (Although I think reddit engineers disagreed with their reasons for move).
I wrote an open source tool that migrates between any 2 relational databases. https://github.com/seanharr11/etlalchemy This includes automatic migration of the schema, constraints, indexes and obviously data. It leverages fast bulk loading tools like mysqlimport, and PostgreSQL's COPY FROM. It doesn't need any config. Just plug and play. The tool uses SQLAlchemy to abstract column types, and handles various column ty…
Thanks much - going to test it between MSSQL and MySQL in a few days here!
Earlier quoted context omitted.
Lack of foreign keys does not effect performance. In fact, having foreign keys is a net-negative performance-wise because it means that each foreign key must be checked for every insert/update/delete.
Errm, we're talking about performance of joins
Earlier quoted context omitted.
But do these "already working" collations include accent-insensitive variants? I didn't think so, and I don't think they are coming in PostgreSQL 10 either. Do you have other information on this?
My misunderstanding seemed to be that "accent-insensitive" turns out to be a precise technical term from MySQL that says "just sort UTF-8 using the American locale and collation, but pretend accented characters are equal to their non-accented versions" which is not a standard collation order in any locale.
Earlier quoted context omitted.
Like other comments here state, in general, use what you know. That said, postgresql has ~always been the better rdbms . Some would argue mysql at times have been a better ~key-value store with ~sql interface. Apparently postgresql is difficult to run in a properly restricted bsd jail. Other than that, I'd be hard pressed to come up with reasons to prefer mysql on technical merit over either postgresql, or, say redis…
I'm running postgresql in a FreeBSD vnet jail without issue. The network stack is not shared as it's a vnet jail. I have it set for per jail sysvipc, new in FreeBSD 11, which was the last thing I needed to fully isolate it from other jails. Is there anything else that's needed to properly restrict the jail?
https://forums.freebsd.org/threads/59371/
Apparently this can(should?) be tweaked a bit since 11-release:
https://www.freebsd.org/cgi/man.cgi?query=jail&sektion=&n=1
> allow.sysvipc A process within the jail has access to System V IPC primitives. This is deprecated in favor of the per-mod- ule parameters (see below). When this parameter is set, it is equivalent to setting sysvmsg, sysvsem, and sysvshm all to ``inherit''.
I interpret that as it still being the case that setting this to the (equivalent of) the deprecated setting, one looses much of the protection a jail normally gives.
One thing that Postgres lacks is accent insensitive collations. Having clients with databases in Spanish, this is one of the reasons I wouldn't consider migrating to Postgres. I know I can use the unaccent extension, but I consider it a poor substitute to proper collations. I guess this isn't a problem for most people because it's never mentioned.
The docs say that locales and LC_COLLATE work, are you sure?
Earlier quoted context omitted.
That post says that they currently work, but there is a new os-independent collation method coming. Edit re your edit: the already working collations are in PG 9.x - the OS independent collations are coming in 10.x. (Hence the post title, "More robust collations with ICU support in PostgreSQL 10")
But do these "already working" collations include accent-insensitive variants? I didn't think so, and I don't think they are coming in PostgreSQL 10 either. Do you have other information on this?