8 ms·

> MySQL is a pretty poor database, and you should strongly consider using Postgres instead. Wow, right on the chin with that one. > More jarring were the peop

> MySQL is a pretty poor database, and you should strongly consider using Postgres instead. Wow, right on the chin with that one. > More jarring were the people who insisted everything was OK (it seems most MySQL users and developers don't really use other databases) I only have anecdata of my usages of MySQL and Postgres but I swear people that cut their teeth on MySQL and have never used Postgres just don't know what they are missing. Yes Postgres can be slower out of the box and yes Postgres has worse connection handling that usually requires a pooler but the actual engine and it's performance makes it worth it in my opinion.

johnmato 5y ago
I have worked with MySQL and every database has its ups and downs.
toast0 5y ago
Vaccuuming sounds much more pleasant than dealing with innodb without file per table?
- leetrout 5y ago
  Yes I would rather have the ability / requirement to vacuum than have unused space in large table files especially one large innodb file.
  - toast0 5y ago
    Unless MySQL changed it since I last looked, the one large innodb file is a big PITA, but otherwise you can do OPTIMIZE TABLE to compact tables; apparently this can sometimes be done in place, but I'm used to it writing to a new file so you'd need room for old and new; and at least for MyISAM locks the table for the whole time, so I hope you've got a way to manage that too, but that's about the same as VACUUM FULL.
    - xd 5y ago
      Innodb can be split into individual per table files and has had this ability for years.
      - toast0 5y ago
        Yeah, but the default used to be one file for everything, and it's hard to split things after you started with that. Especially if your data is sizable.
        evanelias 5y ago
        The default innodb_file_per_table changed to ON in 5.6, released nearly 9 years ago. It's not really that hard to change if you started with OFF, it just requires a logical dump and reload (typically on a replica, followed by some re-cloning and promotion). Companies with sizable data tend to have database engineers who can handle this fairly easily. In any case, it's not an urgent maintenance operation like a VACUUM problem...
        leetrout 5y ago
        It's not nearly the problem now it was ~6 years ago when I was stuck with 8TB in a single file at a small startup. I look around now and you a right. It's really no big deal to move a few terabytes of data around but it sure was a mess back then and I'm once bitten, twice shy.
        evanelias 5y ago
        Having been in a similar situation 11 years ago, from my POV it was waaay easier 6 years ago than it was back then ;) I was fortunate that the startup was willing to devote sufficient time and resources to help me get our DB problems under control -- including getting expert consulting services from Percona, attending conferences, etc. However I've definitely seen some other startups that didn't take DB tech debt seriously enough, and just kicked the can down the road until a major disaster occurred. Anyway though, even aside from improvements in hardware and tooling, managing large DBs just gets less stressful once you've spent some time on the problem. Assuming you successfully solved this 6 years ago, why shy away from it in the future? You almost certainly learned a lot in the process, and the good news is it only gets easier from there!
philliphaydon 5y ago
> Yes Postgres can be slower out of the box Is it though? I read this post earlier this year and it mirrors some similar tests I did back in 2020 when I was just checking basic perf between PostgreSQL / SQL Server / MySQL on my laptop. https://itnext.io/benchmark-databases-in-docker-mysql-postgresql-sql-server-7b129368eed7 https://itnext.io/benchmark-databases-in-docker-mysql-postgr... > A simple conclusion: Postgres engine family is about twice as fast as MySQL engine family, except MariaDB. Also: > Postgres has worse connection handling Is this addressed in PG14? Or is it still to come in PG15? I haven't kept up with the latest Postgres stuff but I thought they were fixing the connection stuff.
- remram 5y ago
  Naive question (I only use PostgreSQL and SQLite): is there any point using MySQL over MariaDB nowadays?
  - throwaway984393 5y ago
    Pretty much only three reasons: you want Enterprise support, you don't want to think about license terms, and you really want to help pay for Larry Ellison's personal island.
  - tehbeard 5y ago
    Last I checked mariaDB still misses some functiinality around JSON, and i don't know what the story is exactly about compat. With the newer X protocol and its collections.
  - evanelias 5y ago
    MySQL 8 has a lot of functionality that MariaDB lacks. People like to criticize MySQL for some bad engineering decisions made decades ago. For whatever reason, often these folks have a more positive view of MariaDB, but without stopping to consider where all those original MySQL engineers went. FWIW one of the footnotes in the original article touches on this too.
- mastax 5y ago
  Pretty surprised about the substantial difference between MariaDB and MySQL.
jayflux 5y ago
> Yes Postgres can be slower out of the box Do you have an up to date source for that?
- leetrout 5y ago
  Not on my phone and i'm headed to bed but I can go educate myself in the morning. Maybe its all better now?
- Izkata 5y ago
  IIRC it's because some of the default settings were chosen back when RAM was measured in MB and low GB and not really updated. work_mem, for example, can typically be safely set to several times its default of 4MB, which then allows individual operations to use more memory before spilling over into temporary files on disk. Of course, that particular example really only matters if you're actually hitting the 4MB limit in your queries, but I think there were some other settings with similar too-low defaults.
- fuy 5y ago
  It's because the default Postgres configuration is very basic and targeted at low-end hardware. Besides, in Postgres you have to tune some of the settings that other databases take care of automagically (work_mem being probably the trickiest one). So the first thing you do after setting up Postgres on a reasonable hardware is tune the config file. There's a lot of advice on the web, and there's pgtune service that makes it very easy to start in the right direction (https://pgtune.leopard.in.ua https://pgtune.leopard.in.ua). Still, you need to know about it to do it, so there's definitely quite a lot of suboptimal Postgres installations out there.
  - dspillett 5y ago
    That isn't unique to pg though: just look at the number of performance questions in dba.stackexchange and on web hosting forums that, once you take out those that turn out to be bad queries and/or non-existent/inappropriate indexes, come down to tuning certain settings in my.ini. I've not used either for a long time so my knowledge may be out of date, but mysql definitely used to be the easiest to get started out of the box which was part of the reason it won out in the shared hosting space. Of course the main reason it won out in that area was because it was faster than pg in many artificial benchmarks because at the time it didn't bother with silly things like transactions (as MyISAM was the default table type), and foreign key constraints, and other necessities…
ploxiln 5y ago
The author was rather focused on the optimizer/scheduler. I can easily believe that it is much less advanced and robust, and messier, in MySQL. I really liked MySQL (and more recently MariaDB), and I have experienced some significant annoyances with Postgres recently, and it's for a completely different set of reasons. Logical Replication is the big one. MySQL has had logical (and "mixed") replication for a decade (or more?). PostgreSQL has gotten built-in logical replication only recently, and it's still very annoying. It doesn't replicate schema change statements, so those have to be applied independently by some external system, and of course it's not going to be timed exactly right so replication will get stuck. And somehow for very lightly active applications generating just a few MB of writes per day, the stuck replication log can back up 10s of GBs per day. And does logical replication across versions for zero-downtime upgrades work in Postres yet? I dunno. Connections you mentioned already, Postgres needs an external connection pooler/proxy, MySQL not nearly so soon. Vacuuming is a problem I never had with MySQL/MariaDB of course. I'm an infrastructure dev, not an DBA or an advanced SQL user, I never used window functions, or wrote a query that filled half the screen, or have a thick web of foreign keys ... If you keep things damn simple so you have confidence in efficiency and performance, then MySQL works pretty damn well in my experience, and Postgres, for all its academic correctness and advanced query feature set, has been pretty damn annoying. And, you can tell MySQL to use a particular index for a query!
- ufmace 5y ago
  This is about where I'm at. I've used both DBs and adminned sites with them. Sure PG has a ton of nice SQL features that are really handy if you want to do any kind of more advanced analysis. I wouldn't be surprised either to learn that it's much more efficient on executing complex queries. But the bottom line is that the great majority of production usage is basic CRUD queries using simple SQL, and a lot of applications will never need to use advanced SQL. The things MySQL does do better, replication and connections like you mentioned, tend to be more suited to keeping big dumb basic sites up and running reliably. I'm usually gonna reach for Wordpress first along with MySQL if I need to set up a basic blog for non-technical people to contribute to. Maybe the DB isn't as cool as it could be, but it works fine, and I hardly ever have need to touch the database itself directly.
bigiain 5y ago
> I swear people that cut their teeth on MySQL and have never used Postgres just don't know what they are missing I seriously trialled and compared Postgres vs MySQL at the start of a major major project, and MySQL had a few clear wins for us (mainly replication) while the features Postgres had weren't in our current roadmap's requirements (the biggest regret that caused me was not having stored procedures). That was in 1998/1999. I now seem to be stuck on a career path where everything is MySQL and switching to Postgres anywhere seems to have huge back pressure from everyone I work with - even though at least half of them know damned well (like I do) that MySQL hasn't been the right choice for a couple of decades almost. :shrug:
- txdv 5y ago
  Just sticking with your old horse, has its problems, but you wont get surprised by new ones
  - Spivak 5y ago
    And the fact that the community and tooling surrounding MySQL is absolutely bonkers massive. It's not that the grass has been trodden down to a path; no there's a 6 lane highway with a rest area and a Cracker Barrel.
    - leetrout 5y ago
      LOL amazing metaphor. The one thing that I've learned recently which surprised me- if you want to cluster MySQL (via partitioned tables or PlanetScale, etc) you cannot use foreign keys. Some of the Postgres compatible tooling (Citus, Cockroach, etc) appears to support foreign keys across partitions / shards. I was quite surprised to see this. Makes sense that not allowing FKs makes the data easier to shard but I never imagined that would be a thing you would have to contend with.
      - vvern 5y ago
        citus has some rather severe limitations around foreign keys. Namely, you can’t use them from any distributed tables. See https://docs.citusdata.com/en/v10.2/develop/reference_ddl.html#adding-removing-constraints https://docs.citusdata.com/en/v10.2/develop/reference_ddl.ht...
mayli 5y ago
Thanks, but no, I don't like slower and 1 process per connection.
dotancohen 5y ago
> Yes Postgres ... has worse connection handling that usually requires a pooler This is the issue. The vast majority of PHP (Wordpress runs ~30% of the internet or something) and Python (Django) devs are not going to write a database connection pooler. I happen to like PHP and love Python, but the low bar to entry on those two (PHP especially) means that the vast majority of devs would be completely lost without the default tooling provided by e.g. php-mysqlng or other prepackaged database connection modules in their default settings with the most trivial of use cases. A slow database can be ignored for a while. The need to add additional code in which the database is no longer a black box can not be ignored.
- makeitdouble 5y ago
  It usually comes down to setting up a pgbouncer in front of the DB, from there you can mostly ignore the pooling layer in your application. It sure is one more step that for MySQL, but we're talking production level DB, and in my experience it's a small task compared to the rest of what you will be doing to have your architecture properly running.
  - dotancohen 5y ago
    But pgbouncer comes with it's own set of bugs and behaviours to be familiar with. Just look at the changelog for the bugs fixed (and yes, there are unfixed bugs as well): https://www.pgbouncer.org/ https://www.pgbouncer.org/ And the FAQs for the unusual behaviours to be aware of and find workarounds for: https://www.pgbouncer.org/faq.html https://www.pgbouncer.org/faq.html I would love nothing more than to be convinced. I find MySQL to be adequate, but far from great. Postgres is described as great by everyone who uses it, however I prefer adequate but reliable over great but leads to downtime.
    - makeitdouble 5y ago
      On your main point, yes, you need to understand how pgbouncer works, it has its quirks and limitations. In particular a dev needs to be aware of how sessions and transactions work if they have some critical transactions. When introducing pgbouncer on one of our rails project we had to fine tune ActiveRecord to play nice, but once it's done there wasn't much to adjust from there. I'm with on how much it would help if it had a magic mode without these quirks, but in my experience you're still ahead of MySQL and its per session configuration quirks for instance. On a day to day basis, you'll rarely be scratching your head about how to deal with the pgbouncer pooling behavior you chose, an you'll still have the option to directly hit the DB on anything you don't trust the pooler to deal with appropriately. For the bugs, those are mostly on the security and configuration side. For the few years I've used it, I never hit a behavioral bug TBH.
takeda 5y ago
When working as an SRE every place that I worked at that used MySQL had at least one situation where MySQL database got corrupted itself without any damaging events (i.e. no broken hardware, no disk filling up (but even that shouldn't corrupt data), no machine crash or hard restart).
- leetrout 5y ago
  This exact situation keeps me up at night. Fear of a db not coming back up in a restart and backups being corrupt as well. We pull our backups into new instances daily and I think that would catch it.
cortesoft 5y ago
> I swear people that cut their teeth on MySQL and have never used Postgres just don't know what they are missing. Yeah, I am one of those people. Needed a database in 2005, and MySQL was the de facto choice. Got used to it and never ran into problems that couldn’t be solved by getting better at schema design and indexing. I never felt limited by MySQL and I am very comfortable with it, so never felt the need to try anything else. I might be missing something, but there is an opportunity cost in switching without a real motivating reason.

johnmato 5y ago

I have worked with MySQL and every database has its ups and downs.

toast0 5y ago

Vaccuuming sounds much more pleasant than dealing with innodb without file per table?

leetrout 5y ago
Yes I would rather have the ability / requirement to vacuum than have unused space in large table files especially one large innodb file.
- toast0 5y ago
  Unless MySQL changed it since I last looked, the one large innodb file is a big PITA, but otherwise you can do OPTIMIZE TABLE to compact tables; apparently this can sometimes be done in place, but I'm used to it writing to a new file so you'd need room for old and new; and at least for MyISAM locks the table for the whole time, so I hope you've got a way to manage that too, but that's about the same as VACUUM FULL.
  - xd 5y ago
    Innodb can be split into individual per table files and has had this ability for years.
    - toast0 5y ago
      Yeah, but the default used to be one file for everything, and it's hard to split things after you started with that. Especially if your data is sizable.
      - evanelias 5y ago
        The default innodb_file_per_table changed to ON in 5.6, released nearly 9 years ago. It's not really that hard to change if you started with OFF, it just requires a logical dump and reload (typically on a replica, followed by some re-cloning and promotion). Companies with sizable data tend to have database engineers who can handle this fairly easily. In any case, it's not an urgent maintenance operation like a VACUUM problem...
        leetrout 5y ago
        It's not nearly the problem now it was ~6 years ago when I was stuck with 8TB in a single file at a small startup. I look around now and you a right. It's really no big deal to move a few terabytes of data around but it sure was a mess back then and I'm once bitten, twice shy.
        evanelias 5y ago
        Having been in a similar situation 11 years ago, from my POV it was waaay easier 6 years ago than it was back then ;) I was fortunate that the startup was willing to devote sufficient time and resources to help me get our DB problems under control -- including getting expert consulting services from Percona, attending conferences, etc. However I've definitely seen some other startups that didn't take DB tech debt seriously enough, and just kicked the can down the road until a major disaster occurred. Anyway though, even aside from improvements in hardware and tooling, managing large DBs just gets less stressful once you've spent some time on the problem. Assuming you successfully solved this 6 years ago, why shy away from it in the future? You almost certainly learned a lot in the process, and the good news is it only gets easier from there!

philliphaydon 5y ago

> Yes Postgres can be slower out of the box Is it though? I read this post earlier this year and it mirrors some similar tests I did back in 2020 when I was just checking basic perf between PostgreSQL / SQL Server / MySQL on my laptop. https://itnext.io/benchmark-databases-in-docker-mysql-postgresql-sql-server-7b129368eed7 https://itnext.io/benchmark-databases-in-docker-mysql-postgr... > A simple conclusion: Postgres engine family is about twice as fast as MySQL engine family, except MariaDB. Also: > Postgres has worse connection handling Is this addressed in PG14? Or is it still to come in PG15? I haven't kept up with the latest Postgres stuff but I thought they were fixing the connection stuff.

remram 5y ago
Naive question (I only use PostgreSQL and SQLite): is there any point using MySQL over MariaDB nowadays?
- throwaway984393 5y ago
  Pretty much only three reasons: you want Enterprise support, you don't want to think about license terms, and you really want to help pay for Larry Ellison's personal island.
- tehbeard 5y ago
  Last I checked mariaDB still misses some functiinality around JSON, and i don't know what the story is exactly about compat. With the newer X protocol and its collections.
- evanelias 5y ago
  MySQL 8 has a lot of functionality that MariaDB lacks. People like to criticize MySQL for some bad engineering decisions made decades ago. For whatever reason, often these folks have a more positive view of MariaDB, but without stopping to consider where all those original MySQL engineers went. FWIW one of the footnotes in the original article touches on this too.
mastax 5y ago
Pretty surprised about the substantial difference between MariaDB and MySQL.

jayflux 5y ago

> Yes Postgres can be slower out of the box Do you have an up to date source for that?

leetrout 5y ago
Not on my phone and i'm headed to bed but I can go educate myself in the morning. Maybe its all better now?
Izkata 5y ago
IIRC it's because some of the default settings were chosen back when RAM was measured in MB and low GB and not really updated. work_mem, for example, can typically be safely set to several times its default of 4MB, which then allows individual operations to use more memory before spilling over into temporary files on disk. Of course, that particular example really only matters if you're actually hitting the 4MB limit in your queries, but I think there were some other settings with similar too-low defaults.
fuy 5y ago
It's because the default Postgres configuration is very basic and targeted at low-end hardware. Besides, in Postgres you have to tune some of the settings that other databases take care of automagically (work_mem being probably the trickiest one). So the first thing you do after setting up Postgres on a reasonable hardware is tune the config file. There's a lot of advice on the web, and there's pgtune service that makes it very easy to start in the right direction (https://pgtune.leopard.in.ua https://pgtune.leopard.in.ua). Still, you need to know about it to do it, so there's definitely quite a lot of suboptimal Postgres installations out there.
- dspillett 5y ago
  That isn't unique to pg though: just look at the number of performance questions in dba.stackexchange and on web hosting forums that, once you take out those that turn out to be bad queries and/or non-existent/inappropriate indexes, come down to tuning certain settings in my.ini. I've not used either for a long time so my knowledge may be out of date, but mysql definitely used to be the easiest to get started out of the box which was part of the reason it won out in the shared hosting space. Of course the main reason it won out in that area was because it was faster than pg in many artificial benchmarks because at the time it didn't bother with silly things like transactions (as MyISAM was the default table type), and foreign key constraints, and other necessities…

ploxiln 5y ago

The author was rather focused on the optimizer/scheduler. I can easily believe that it is much less advanced and robust, and messier, in MySQL. I really liked MySQL (and more recently MariaDB), and I have experienced some significant annoyances with Postgres recently, and it's for a completely different set of reasons. Logical Replication is the big one. MySQL has had logical (and "mixed") replication for a decade (or more?). PostgreSQL has gotten built-in logical replication only recently, and it's still very annoying. It doesn't replicate schema change statements, so those have to be applied independently by some external system, and of course it's not going to be timed exactly right so replication will get stuck. And somehow for very lightly active applications generating just a few MB of writes per day, the stuck replication log can back up 10s of GBs per day. And does logical replication across versions for zero-downtime upgrades work in Postres yet? I dunno. Connections you mentioned already, Postgres needs an external connection pooler/proxy, MySQL not nearly so soon. Vacuuming is a problem I never had with MySQL/MariaDB of course. I'm an infrastructure dev, not an DBA or an advanced SQL user, I never used window functions, or wrote a query that filled half the screen, or have a thick web of foreign keys ... If you keep things damn simple so you have confidence in efficiency and performance, then MySQL works pretty damn well in my experience, and Postgres, for all its academic correctness and advanced query feature set, has been pretty damn annoying. And, you can tell MySQL to use a particular index for a query!

ufmace 5y ago
This is about where I'm at. I've used both DBs and adminned sites with them. Sure PG has a ton of nice SQL features that are really handy if you want to do any kind of more advanced analysis. I wouldn't be surprised either to learn that it's much more efficient on executing complex queries. But the bottom line is that the great majority of production usage is basic CRUD queries using simple SQL, and a lot of applications will never need to use advanced SQL. The things MySQL does do better, replication and connections like you mentioned, tend to be more suited to keeping big dumb basic sites up and running reliably. I'm usually gonna reach for Wordpress first along with MySQL if I need to set up a basic blog for non-technical people to contribute to. Maybe the DB isn't as cool as it could be, but it works fine, and I hardly ever have need to touch the database itself directly.

bigiain 5y ago

> I swear people that cut their teeth on MySQL and have never used Postgres just don't know what they are missing I seriously trialled and compared Postgres vs MySQL at the start of a major major project, and MySQL had a few clear wins for us (mainly replication) while the features Postgres had weren't in our current roadmap's requirements (the biggest regret that caused me was not having stored procedures). That was in 1998/1999. I now seem to be stuck on a career path where everything is MySQL and switching to Postgres anywhere seems to have huge back pressure from everyone I work with - even though at least half of them know damned well (like I do) that MySQL hasn't been the right choice for a couple of decades almost. :shrug:

txdv 5y ago
Just sticking with your old horse, has its problems, but you wont get surprised by new ones
- Spivak 5y ago
  And the fact that the community and tooling surrounding MySQL is absolutely bonkers massive. It's not that the grass has been trodden down to a path; no there's a 6 lane highway with a rest area and a Cracker Barrel.
  - leetrout 5y ago
    LOL amazing metaphor. The one thing that I've learned recently which surprised me- if you want to cluster MySQL (via partitioned tables or PlanetScale, etc) you cannot use foreign keys. Some of the Postgres compatible tooling (Citus, Cockroach, etc) appears to support foreign keys across partitions / shards. I was quite surprised to see this. Makes sense that not allowing FKs makes the data easier to shard but I never imagined that would be a thing you would have to contend with.
    - vvern 5y ago
      citus has some rather severe limitations around foreign keys. Namely, you can’t use them from any distributed tables. See https://docs.citusdata.com/en/v10.2/develop/reference_ddl.html#adding-removing-constraints https://docs.citusdata.com/en/v10.2/develop/reference_ddl.ht...

mayli 5y ago

Thanks, but no, I don't like slower and 1 process per connection.

dotancohen 5y ago

> Yes Postgres ... has worse connection handling that usually requires a pooler This is the issue. The vast majority of PHP (Wordpress runs ~30% of the internet or something) and Python (Django) devs are not going to write a database connection pooler. I happen to like PHP and love Python, but the low bar to entry on those two (PHP especially) means that the vast majority of devs would be completely lost without the default tooling provided by e.g. php-mysqlng or other prepackaged database connection modules in their default settings with the most trivial of use cases. A slow database can be ignored for a while. The need to add additional code in which the database is no longer a black box can not be ignored.

makeitdouble 5y ago
It usually comes down to setting up a pgbouncer in front of the DB, from there you can mostly ignore the pooling layer in your application. It sure is one more step that for MySQL, but we're talking production level DB, and in my experience it's a small task compared to the rest of what you will be doing to have your architecture properly running.
- dotancohen 5y ago
  But pgbouncer comes with it's own set of bugs and behaviours to be familiar with. Just look at the changelog for the bugs fixed (and yes, there are unfixed bugs as well): https://www.pgbouncer.org/ https://www.pgbouncer.org/ And the FAQs for the unusual behaviours to be aware of and find workarounds for: https://www.pgbouncer.org/faq.html https://www.pgbouncer.org/faq.html I would love nothing more than to be convinced. I find MySQL to be adequate, but far from great. Postgres is described as great by everyone who uses it, however I prefer adequate but reliable over great but leads to downtime.
  - makeitdouble 5y ago
    On your main point, yes, you need to understand how pgbouncer works, it has its quirks and limitations. In particular a dev needs to be aware of how sessions and transactions work if they have some critical transactions. When introducing pgbouncer on one of our rails project we had to fine tune ActiveRecord to play nice, but once it's done there wasn't much to adjust from there. I'm with on how much it would help if it had a magic mode without these quirks, but in my experience you're still ahead of MySQL and its per session configuration quirks for instance. On a day to day basis, you'll rarely be scratching your head about how to deal with the pgbouncer pooling behavior you chose, an you'll still have the option to directly hit the DB on anything you don't trust the pooler to deal with appropriately. For the bugs, those are mostly on the security and configuration side. For the few years I've used it, I never hit a behavioral bug TBH.

takeda 5y ago

When working as an SRE every place that I worked at that used MySQL had at least one situation where MySQL database got corrupted itself without any damaging events (i.e. no broken hardware, no disk filling up (but even that shouldn't corrupt data), no machine crash or hard restart).

leetrout 5y ago
This exact situation keeps me up at night. Fear of a db not coming back up in a restart and backups being corrupt as well. We pull our backups into new instances daily and I think that would catch it.

cortesoft 5y ago

> I swear people that cut their teeth on MySQL and have never used Postgres just don't know what they are missing. Yeah, I am one of those people. Needed a database in 2005, and MySQL was the de facto choice. Got used to it and never ran into problems that couldn’t be solved by getting better at schema design and indexing. I never felt limited by MySQL and I am very comfortable with it, so never felt the need to try anything else. I might be missing something, but there is an opportunity cost in switching without a real motivating reason.