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
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
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
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
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
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
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
