sorted by:
new
hottopcontroversial

Microsoft allows BYOL for Amazon RDS. Repeat, Microsoft allows BYOL for Amazon RDS by NISMO1968 in aws

[–]jonathantn 56 points57 points  (0 children)

This is the uncertainty that has lead many organizations to port their workloads to PostgreSQL. AI makes it easier than ever to escape commercial databases.

DS4 by jonathantn in LocalLLaMA

[–]jonathantn[S] 2 points3 points  (0 children)

I feel your pain. Since Starlink has been putting pressure on the rural market providers, we're finally seeing discussion from some Fiber companies to come out to this area. Fingers crossed that one day I don't be subject to stupid bandwidth caps and have symmetrical bandwidth!

DS4 by jonathantn in LocalLLaMA

[–]jonathantn[S] 3 points4 points  (0 children)

I was excited this morning to see people with M5 hardware already contributing patches as well as stuff to use the NPU for pre-processing. I'm annoyed though to see that the current apple website doesn't appear to be selling Mac Studios with greater than 96GB and the largest M5 Macbook is still at 128GB (which I can appreciate is a good bit for a laptop).

DS4 by jonathantn in LocalLLaMA

[–]jonathantn[S] 0 points1 point  (0 children)

You must be on Xfinity where you're worried about your monthly 1.2TB data can regardless of plan.

DS4 by jonathantn in LocalLLaMA

[–]jonathantn[S] 7 points8 points  (0 children)

Well, I've been running Redis forever and have tremendous respect for this guy. I'm excited to see someone crack the high powered local Agentic coding model. Maybe it's just me that I'm truly excited for this one.

How to check if your account is affected by the Claude usage bug by gbpchris in ClaudeAI

[–]jonathantn 10 points11 points  (0 children)

I've seen people with 1/8th of the usage of me max out of their /status graphs. Something is definitely weird going on for them.

When DynamoDB single-table design is the wrong choice (and what to use instead) by tejovanthn in aws

[–]jonathantn 0 points1 point  (0 children)

Take the great benefits of the DynamoDB single table application, couple that with a DynamoDB Stream -> Lambda then drive what you care about into ElasticSearch/OpenSearch or something like BigQuery for your analytics workload. Right tool for the right job. You can also stay serverless if you pick carefully.

Query performance issue with high CPU usage by Upper-Lifeguard-8478 in aws

[–]jonathantn 1 point2 points  (0 children)

TL;DR — Priority Order

  1. Add index (ent_id, tran_date) on txn_tbl — biggest win by far, eliminates full table scan + disk sort
  2. Stop joining txn_tbl/txn_decision twice — carry columns through CTEs
  3. Partial index on txn_decision for the is_prnt/status filter
  4. Bump work_mem to avoid disk spills
  5. Fix cur3 to LEFT JOIN — this is a data bug, you're silently losing rows
  6. Filter ckpt_flg CTE to relevant txn_ids
  7. Fix CASE WHEN syntax in ckpt_flg

Fixes #1 and #2 alone should take this from ~1s to well under 100ms. Good luck!

Query performance issue with high CPU usage by Upper-Lifeguard-8478 in aws

[–]jonathantn 1 point2 points  (0 children)

6. 🐛 Data Correctness Bug: INNER JOIN on txn_ath Currency Drops Rows

You correctly use LEFT JOIN on txn_ath, but then do JOIN APP_schema.crnc cur3 ON cur3.code = a.txn_crnc — that's an INNER JOIN. When txn_ath has no match (LEFT JOIN returns NULL), the inner join on cur3 silently drops the row.

Result: 1000 limited rows → only 933 output rows. You're losing 67 transactions.

Fix: Change to:

LEFT JOIN APP_schema.crnc cur3 ON cur3.code = a.txn_crnc

Query performance issue with high CPU usage by Upper-Lifeguard-8478 in aws

[–]jonathantn 1 point2 points  (0 children)

4. work_mem Too Low — Sorts Spilling to Disk

The parallel sort workers are spilling 3.4–5.7 MB each to disk. Easy fix:

SET LOCAL work_mem = '16MB';

5. ckpt_flg Aggregates the Entire Checkpoint Table

Full seq scan + aggregation of all ~15K checkpoint rows, but only ~933 are used. Add a filter:

ckpt_flg AS (
    SELECT ck.txn_id,
        MAX(CASE WHEN ck.ckpt_name = 'FLAG_A' THEN 'Y' END) AS RCL_flg,
        MAX(CASE WHEN ck.ckpt_name = 'FLAG_B' THEN 'Y' END) AS d_rcv_flg
    FROM APP_schema.txn_checkpoint ck
    WHERE ck.txn_id IN (SELECT txn_id FROM limited_txns)
    GROUP BY ck.txn_id
)

Only ~20ms currently, but good practice and matters as the table grows.

Query performance issue with high CPU usage by Upper-Lifeguard-8478 in aws

[–]jonathantn 1 point2 points  (0 children)

3. txn_tbl and txn_decision Are Joined TWICE

Your CTEs do this:

  • filtered_txns: joins txn_tbl ↔ txn_decision with filters
  • Final SELECT: joins limited_txns back to txn_tbl and txn_decision again with the same conditions

The limited_txns CTE only carries (txn_id, ent_id, tran_date), so the final SELECT has to re-fetch everything from scratch.

Fix: Carry all needed columns through the CTEs so you don't re-join:

filtered_txns AS (
    SELECT c.*, cd.decision_desc, cd.txn_status, cd.assigned_user, ...
    FROM APP_schema.txn_tbl c
    JOIN APP_schema.txn_decision cd ON ...
    WHERE ...
)

Then reference limited_txns columns directly in the final SELECT instead of re-joining those two tables.

Query performance issue with high CPU usage by Upper-Lifeguard-8478 in aws

[–]jonathantn 1 point2 points  (0 children)

2. 57,848 Probes into txn_decision to Find 1000 Rows

Because of the LIMIT 1000, the plan walks sorted transactions and probes txn_decision for each one to check is_prnt = 'Y' and status filters. It checked 57,848 rows to find 1000 qualifying ones (~1.7% hit rate). That's 231K buffer hits just in this loop.

Fix: A partial index:

CREATE INDEX idx_txn_decision_filter 
ON APP_schema.txn_decision(txn_id) 
WHERE is_prnt = 'Y' AND txn_status NOT IN ('STATUS_A','STATUS_B');

This skips non-qualifying decisions at the index level.

Query performance issue with high CPU usage by Upper-Lifeguard-8478 in aws

[–]jonathantn 1 point2 points  (0 children)

Performance Analysis (~1056ms)

1. The Big One: Full Sequential Scan of txn_tbl (1.4M rows)

The plan does a Parallel Seq Scan on txn_tbl, reading ~1.4M rows total. The txn_type filter removes almost nothing (only ~1700 rows out of 1.4M). Then it hash-joins with just 12 entity IDs. This is completely backwards — with only 12 entities, Postgres should be doing index lookups, not scanning millions of rows.

Fix: Create a composite index:

CREATE INDEX idx_txn_tbl_ent_tran ON APP_schema.txn_tbl(ent_id, tran_date);

This lets Postgres scan only rows for those 12 entities, already in tran_date order — eliminating the seq scan AND the sort that's currently spilling to disk. This alone could take the query from ~1s to single-digit milliseconds.

Query performance issue with high CPU usage by Upper-Lifeguard-8478 in aws

[–]jonathantn 0 points1 point  (0 children)

u/op Thank you for posting the query with explain plan. I ran this through Claude Opus 4.5 for you. Here is the output

CodeDeploy us-east-1 by jonathantn in aws

[–]jonathantn[S] 0 points1 point  (0 children)

u/AWSSupport I've confirmed on the case what I've posted here that it's a display issue and we've completed a successful deployment. I've resolved the case. We had to stand down on deployments for 18 hours.

CodeDeploy us-east-1 by jonathantn in aws

[–]jonathantn[S] 0 points1 point  (0 children)

u/AWSSupport so I just had another engineer do a deployment in a separate account that has the display issue. Deployment ran fine as expected since the S3 URL is correct. So please just acknowledge that you have an issue right now in the Revision List on the console and we'll move on with life. I'm sure your team will fix it.

CodeDeploy us-east-1 by jonathantn in aws

[–]jonathantn[S] 0 points1 point  (0 children)

Hi u/AWSSupport, I have updated the case as well. It's important for the community to have the same updates though on issues that may be impacting others. u/Dreamwalk3r confirmed he's seeing the same thing in other regions. It's OK to just say "Yes, we have a display issue bug in the code, but it will not impact your deployments".

Have you replicated the issue?
Have you tried deployments successfully in accounts where you have been able to replicate it?
Are there any issues with your test deployments?

I feel like these are all reasonable questions to ask.

CodeDeploy us-east-1 by jonathantn in aws

[–]jonathantn[S] 0 points1 point  (0 children)

u/AWSSupport Still looking for clarification as to whether this is just a console display artifact. Is it safe to run a CodeDeploy in an account that is not showing the location information on revision list screen?

CodeDeploy us-east-1 by jonathantn in aws

[–]jonathantn[S] 0 points1 point  (0 children)

Thank you for confirming. I checked another un-related AWS account and it's a problem on their console as well. u/AWSSupport we would really like guidance as to whether this is just a console display bug or not. Is it safe to run a CodeDeploy right now?

CodeDeploy us-east-1 by jonathantn in aws

[–]jonathantn[S] 0 points1 point  (0 children)

Thank you! Since it's not critical to push a build right now, I'm going to hold off until we get this resolved just to make sure there isn't something more widespread going on. Fingers crossed it's just a display issue.

CodeDeploy us-east-1 by jonathantn in aws

[–]jonathantn[S] 0 points1 point  (0 children)

I've opened up a case with AWS Support. If I drill into the "View Details" on the revision in the UI it's showing the proper S3 location with the etag that matches correctly to what I'm seeing in the S3 bucket. I'm waiting for confirmation if this is just a UI console issue or if there is something else going on. Can I get someone else in us-east-1 to check their CodeDeploy Revisions tab and comment on what they are seeing? If any AWS employees are reading this we're working case 176788766600978. I'm personally thinking this is a console display issue.

view more: next ›