I believe this thread qualifies for the funniest thread of 2021 (so far). And
yes, this is a top post. :-)
Mike Sofen
-Original Message-
From: Alvaro Herrera
Sent: Thursday, July 08, 2021 3:29 PM
To: Justin Pryzby
Cc: Nagaraj Raj ; pgsql-performa...@postgresql.org
Subject: Re
Hi Zoltan,
I haven’t needed to use a cursor in 20 years of sometimes very complex sql
coding.
Why? Cursors result in RBAR (row by agonizing row) operation which eliminates
the power of set-based sql operations. Performance will always suffer –
sometimes to extremes. I’m all about fas
h everything Postgres and
the documentation is where most of us turn for guidance.
And thank you Tom (and others), for your willingness to share these (and
many, many other) insights - it is so powerful when facts connect with
database reality.
Mike Sofen
te set and then a new row is created.
To me, that says, put an index on end_date so you can find/query them quickly,
and create partitions on a static date so the rows (and indexes) aren’t always
being updated.
Mike Sofen
use a
“StartTime” column to anchor the row in a partition. The relatively few rows
with a null EndTime don’t need the power of partitioning, just an index to find
them.
Mike Sofen
In my experience, that 77ms will stay quite constant even if your db grew to >
1TB. Postgres IS amazing. BTW, for a db, you should always have provisioned
IOPS or else your performance can vary wildly, since the SSDs are shared.
Re Lambda: another team is working on a new web app using Lam
same test? There is nothing else obvious
about your data/structure that could result in such terrible performance.
Mike Sofen
From: Jean Baro [mailto:jfb...@gmail.com]
Sent: Wednesday, December 27, 2017 7:14 AM
Hello,
We are still seeing queries (by UserID + UserCountry) taking
