At this point, relatively simply,

[poxoja9630]

The solution was to increase the column slugto 512 characters and try again. Still on the typing, one of my tables originally had integer primary keys, but at some point I decided to change those keys to UUID strings. When I made this change in SQLite, I migrated the table manually, but I didn't realize that I had left the primary key column of that table set to integer. Once again, SQLite stored my UUIDs in that column and even indexed them. But to transfer them to PostgreSQL, I had to fix the schema and properly declare those keys as strings.

At this point, relatively simply, I could switch from a SQLite database to whatsapp philippines number an equivalent PostgreSQL database by changing the database URL in a configuration file and restarting the Python server. I manually tested some queries on my development laptop and felt like everything was faster with the PostgreSQL database, which was an encouraging first observation. Creating a Performance Test My next task was to create an automatable and reproducible test so that I could test the system under both databases and determine which one performed better. Simple, right? In this section I go into a lot of technical details regarding the design and implementation of my test script.

While I consider this an important context for anyone interested in undertaking a similar effort, feel free to skip to the results if that is the only thing you care about. Unfortunately, it is very difficult to design a test that covers all the ways this system can be used due to the large number of possibilities, because I designed it to allow the user to create a large number of different queries. For example, it allows the user to get traffic statistics over a period of days, weeks, or even years, and to sort the results by article, author, team, product, computer language, written language, or year of publication.



The user can also split the traffic results by country of origin. When retrieving articles, the user can choose to see all translations of an article grouped with the original. For all queries, the user can filter a section of the dataset by any combination of authors, teams, products, computer languages, written languages, or publication dates. And all of this can be done for Twilio or SendGrid blogs, or for both blogs combined. To avoid venturing into an unfamiliar path, I decided to focus on the most common use cases. So I created a list of API requests representing them.