In our last blog post on using Postgres for statistics, I covered some of the decisions on how to handle calculated columns in PostgreSQL. I chose to go with adding extra columns to the same table and inserting the calculated values into these new columns. Today’s post is going to cover how to implement this solution using Pl/pgSQL.
For those of you who have a bad taste in your mouth from earlier run-ins with regexs, this will be more use case focused and I will do my best to explain the search patterns I used.
Today we are going to examine methods for calculating z-scores for our data in the database. We want to do this transformation because, when we carry out logistic regression we want to be able to compare the effects of the different factors on fire probability.
I was sent a link to a tweet regarding election night forecasting and of course the default questions was... could be run under PL/R inside Postgres. Like about everything else at Crunchy Data we believe all things are better with Postgres.
In the last post of this series we introduced trying to model fire probability in Northern California based on weather data. We showed how to use SQL to do data shaping and preparation.
Today's post is going to work through the advice I received on using joins rather than subqueries.
Learn how you can leverage Python and Pandas from directly inside PostgreSQL to build your own recommendation engine.
Crunchy Data is proud to announce the initial release of our application developer portal. An awesome team has been working behind the scenes to bring together this website to help application developers find all their Postgres needs in one place.
Learn how to use PostgreSQL for all your JSON needs plus free learning resources.
Learn how to do address normalization with PostgreSQL and PostGIS to provide a standard set of addresses for consistent searches over a data set.