I was able to pull some stats with pgstattuple and nothing looks
particularly hinky to me.
version: 4
tree_level: 2
index_size: 499589120
root_block_no: 412
internal_pages: 194
leaf_pages: 54572
empty_pages: 0
deleted_pages: 6218
avg_leaf_density: 90.08
leaf_fragmentation: 0.01
For flavor, If I r
On 11/28/23 18:13, Owen Nelson wrote:
> Aurora is not really Postgres
Oh geez, I didn't realize there was such a divide. This is my first look
at Aurora and I thought it was just a hosted postgres offering.
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html
> Aurora is not really Postgres
Oh geez, I didn't realize there was such a divide. This is my first look at
Aurora and I thought it was just a hosted postgres offering.
Still, I'll take what I can get. Hopefully, some of this will carry over.
Owen Nelson writes:
>> Are your ANALYZE stats up to date on this table?
> It's a very good question! Right now, I'm taking it on faith that
> autovacuum and autoanalyze are keeping things up to date, but if I'm honest
> I've been getting some conflicting information from pg_stat_user_tables and
>
Embarrassed to say that it's been so long since I participated in a mailing
list I neglected to ensure my replies were directed back at the list rather
than select individuals.
I'll recap what I shared for the list here, for posterity.
@Boris
This is where the iteration aspect is tricky. I don't
On Wed, 29 Nov 2023 at 11:23, Owen Nelson wrote:
> "message_payload_not_null_pidx" btree (expiration) WHERE payload IS NOT
> NULL
> I periodically run a query like this:
> ```
> UPDATE message SET payload = NULL WHERE id IN (
> Update on message (cost=1773.41..44611.36 rows=5000 width=283)
Owen Nelson writes:
> The hope is the sub-select would leverage the index
> "message_payload_not_null_pidx" but when I `EXPLAIN ANALYZE` the query, I
> see a seq scan instead.
I think your problem is the horrid rowcount misestimation here:
> -> Seq Scan on messag
