PostgreSQL

04 November 2025 09:51

Hi QWxp. I'm still using apgDiff since 10 years ago.

* dump production & dev ddl
* diff it with apgDiff
* roll the diff into test env ( one mirror containing full production data )
* if it pass, deploy.
* commit & tag the diff within a release.
* if something happen. rollback from that tag.

automate the process by using simple bash script. no complex ci/cd setup.

PostgreSQL

04 November 2025 05:21

Hi, I wants to try bloom index
If anyone already tried can you pls brief how it helped practically to access early

PostgreSQL

03 November 2025 05:57

yeah, sometimes i do miss solving complex problem by myself. now i prefer trade it to get higher leverage (sales, business network, etc).

PostgreSQL

03 November 2025 05:14

Btw, over the past three years, I’ve been outsourcing almost all my database problems to major LLMs — complex stuff including CTEs, window, recursive, even regex.

I just attach DDL, prompt, and done. I barely write complex queries myself anymore. Kinda weird, but, I get to watch more Lex Fridman podcasts now. LOL.

Do you guys do the same?

PostgreSQL

03 November 2025 01:42

Arman , try to write it down on your own language, than translate it to English. You may be speaking while your computer writes it down, and it is not working this way.

PostgreSQL

02 November 2025 22:44

Maybe it's just a newly developed language variant, that we, dinosauros, don't understand?

PostgreSQL

01 November 2025 17:25

You say im doing false?

PostgreSQL

01 November 2025 14:46

/switch_model_chatgpt5

PostgreSQL

01 November 2025 14:43

Sorry, but I’m unable to assist because your question is unclear. It’s difficult to understand exactly what you’re trying to achieve with your transaction and reporting tables. Please explain your setup again using clear examples, such as table names, key fields, and what kind of reports or operations you want to perform. This will help me provide a useful answer.

PostgreSQL

01 November 2025 14:39

I’m sorry, but as a large language model, I’m unable to assist with that request right now. I hope you find the right solution for your needs. If you have other questions, please let me know.

PostgreSQL

01 November 2025 14:38

I do not understand what you are looking for

PostgreSQL

01 November 2025 14:33

Hello friends, I want to do something. I want to do something. When I have accounting in my service, I have one that is used to store payments, wallets, transactions, and transactions. Because I am in the middle of my transactions, I came to my transaction table. I used UID. Every time I want to select a report, I find it for each user. It is a bit difficult for me to find it with a specific user ID. Do you think it is wrong? When I create transactions, I create a separate table for transaction reports. Then I show the reports that the user needs to see in a more limited way. With the primer, when it is added, and I put these two queries in one transaction at the same time. Do you think this is wrong? I separate the report altogether, for example, a more important table from transactions. This will not make the database heavy or, for example, an additional table, because it is easier this way.

PostgreSQL

01 November 2025 11:43

One of my favourite things to do is

SELECT id, name FROM table_a WHERE NOT EXISTS (SELECT 1 FROM table_b WHERE some_condition)

PostgreSQL

01 November 2025 11:39

Is it?🤔 i thought that was very fast

PostgreSQL

01 November 2025 11:23

I usually try to swap it for a more explicit join, especially when working with many many values

PostgreSQL

04 November 2025 08:37

Bloom indexes have a very distinct use case. Many columns that are sparsely filled and get queried in unpredictable combinations. If your data is like that, you'll probably benefit. If it's not, bloom is probably not worth trying.

PostgreSQL

03 November 2025 09:19

Hi, try to look at citus extension, it can actually help you, but you need to do research by yourself

PostgreSQL

03 November 2025 05:31

Nope, SQL is not complex and I would do anything to avoid watching Lex Fridman podcast.

PostgreSQL

03 November 2025 05:02

Patiently waiting durov and musk to drop grok into telegram. So we can ditch this crap and have real productive talks.😅

PostgreSQL

02 November 2025 22:56

Your english is insanely non-sensial, please use another translation method from your native language for understandability.

PostgreSQL

01 November 2025 17:35

I don't understand your question.

PostgreSQL

01 November 2025 16:31

Sounds very much like trying to optimise something far to early.

For transaction reporting, I would have thought building the report from the *actual* transaction data is the most important. For auditability you want the least complexity here and definitely don't want duplicated data.

If you're so concerned by the 'size' of your main transaction record, then you're likely better off splitting that.

But it's very hard for people here to give any actual advice if you don't at least share table structures (via a pastebin site).

PostgreSQL

01 November 2025 14:46

Can i send to your pv ?

PostgreSQL

01 November 2025 14:40

Look, there's a problem. I want to store two data and two different tables at the same time. While the tables may be duplicates, their data, but I want one for reporting. It has fewer attributes than, for example, that one and the other, for example, the main bank transaction. For example, I choose one separately for reporting transactions and one separately for that transaction process in the database because that transaction process in the database has a uid and every time I want to access it and show it to the user, this is problematic and it becomes very slow. The solution I used is good now.

PostgreSQL

01 November 2025 14:38

He thinks you are a LLM

PostgreSQL

01 November 2025 14:37

@unfoxo

PostgreSQL

01 November 2025 11:44

Ah yes! I do that a lot too

PostgreSQL

01 November 2025 11:39

Maybe it’s time to visit my (NOT) EXISTS lessons

PostgreSQL

01 November 2025 11:33

Well... Not really. It denys some fast direct algorithms for some indexes — but that part is fast anyway, there is no urge to fix it in this query.

Splitting may also switch to a nested loop, yes, but... Not because in/any is slow — it's because another set of problems.

PostgreSQL

01 November 2025 11:22

Isn't "in/any" the source of all evils?