October 17, 2026
Dear [Hiring manager's name],
Most of what I build at Prairieland Grain Cooperative are the reports that tell forty branch managers whether today's grain intake numbers actually match what the elevators are reporting, and getting that query wrong means someone makes a bad call before lunch. I'm applying to [Company name] because I want to keep writing SQL that people actually depend on to make same-day decisions.
Rebuilding our daily intake-reconciliation report, which used to take 40 minutes to run and occasionally timed out, into a query using proper indexing and a materialized view cut runtime to under 90 seconds and ended the timeouts completely. A related stored-procedure rewrite for our pricing calculations cut a recurring rounding-error bug that had affected about 200 transactions a month down to zero.
I write PL/SQL and PL/pgSQL depending on the system, since we run both Oracle and PostgreSQL databases, and I'm comfortable reading an execution plan well enough to know whether a slow report is a missing index or a bad join. I document every stored procedure I write so the next developer doesn't have to reverse-engineer my logic.
I'd welcome a conversation about which reports or stored procedures at [Company name] could use that same kind of attention and where four years of treating query performance seriously could help. I'm available for an interview at your convenience. Thank you for considering my application.
Kind regards,
Morgan Martin