I even saw something similar when I went to the ER recently. Even doctors will pickup on one thing you say and draw conclusions from that and dismiss everything else.

This pattern seems really common, and is what scares me about the future in general. The 'experts' concentrate on the stuff they understand / are best to the detriment of where the actual focus needs to be. In a lot of cases, this is despite the insistence of the supposed non-expert who is the one suffering as a result.

Some of the worst cases are as a child, where you get in trouble twice. First for wasting adults time because you didn't tell them properly, and then again for pointing out that you did.

Elderly relatives writhing in pain, only to have doctors say it's indigestion (it was a perforated ulcer and an uncle had previously died from a wrongly diagnosed ulcer perforating). My partner was misdiagnosed with flu when it was pneumonia which then developed into pleurisy (I'd never seen either of the latter, but was telling the doctor that's what the symptoms looked like - 15 years later he still suffers pain from the pleurisy). I had an arm paralyzed through severe pain and the consultant doctor planned an operation "to cut the nerve" - I said I thought it was a frozen shoulder and that such a procedure was unnecessary; 6 months later the paralysis began to subside and the consultant agreed it was a frozen shoulder). Another relative died of bowel cancer that was said to be back pain (she died in the hospital where she worked). I know of several people who were telling the doctor they had cancer, only to have the doctors dismiss it as trivial, with most of these people dying because of their untreated cancer. As a child I had joint pains for years that were diagnosed as "growing pains" but turned out to a hip disease (younger cousins ended up with the same condition and because I'd already had it, they were more readily diagnosed by family members).

In both directions (treating trivial as serious and treating serious as trivial) I've seen so many mistakes. I'd be much happier to see a doctor google the symptoms rather than jump to a conclusion about what is wrong.

There's a famous anecdote where junior doctors are taught the importance of observation, by senior doctors tricking them into tasting urine. It doesn't seem to be a lesson they learn. Even when their own objective test results are contra-indicative of their pre-judgement I've seen doctors scratch their heads but stick with their incorrect pre-judgement.

When doctors I know have a family member go into hospital, you should see how attentive my doctor friends get concerning what is being said and done to their relatives. Some doctors will not even allow relatives to go into hospital for non-emergency treatment at certain times of year (because of timetabling there can be very inexperienced doctors on duty at certain times of the year).

As someone who suffered through that on _both_ shoulders I can sympathize. For me, the doctor missed it. The chiropractor I was sent to, took one look and said it was 'frozen shoulder'. I have never even heard of such a thing before. It took nearly two years to get full movement on my right shoulder. Then the left froze :-(

I'm just curious. Are these experiences in the UK?

I have seen and heard of some similar things, but my experience is only with the US healthcare system.

If I’d been in the patch submitter’s shoes, I wouldn’t have thought twice about writing off that community.

If I had gotten your reply, instead: 100% fair play, thank you for your consideration, and send my love to the dev team.

Messaging matters.

Honestly, if someone's spending time working on a high value open source project (which PG absolutely is), I'd rather they spend less time (than I do) crafting their internet comments to sound nice and more time contributing to society. And I hope people who actually use the product feel the same way, understand why every single use case can't be carefully considered every time it comes up, and don't take it personally.

People like to think they can escape politics. They can’t. Any group of >1 humans will involve politics.

Learning how to be respectful and polite is like learning how to touch type: it’s a small, painful price to pay once, for a lifetime of copious reward.

Except georgebarnett and jarym.

Or perhaps that was the point, that PostgreSQL isn’t doing much! :)

> Actually as great as Postgres is and as generally approachable the community is - my experience was the same a few times and I read it on the mailing list happening to others: - jarym

It seems that despite things not being perfect (and they never are), these people are still having positive experiences with the product and the community overall. So, to restate, some people care enough to post about it on HN, but nobody (who continues to use PG, and there are a lot of us) cares all that much.

Linus was trying to make things work, with profanity. Postgres couldn't be bothered.

Sure, performative profanity isn't everyone's cup of tea, but milquetoast passive-aggressive dismissals of people like OP who ARE TOTALLY RIGHT aren't actually nice.

It's ten years too soon to conclude that Torvalds backing away from abrasive behaviour didn't kill Linux.

That said, I feel that a strong and positive community around a project is always an asset. I’ve seen many more projects fail due to community interaction being bad than I have from it being good.

The patch author does the "initial" work. But then it's up to the team to learn the patch, understand it and keep maintaining it.

Every line of code is baggage.

If there is no demand for something at the time, it makes sense for maintainers to reject that. It's up to them to maintain that patch from now on.

No one is asking them to. An open source project is not a corporation, it has no shareholders who require growth at all costs. So someone doesn't contribute to the project, if there's enough other contributors to keep it healthy then who care? No need to try and get every single potential contributor to contribute code to the project.

It's not hard.

A second, separate thought. Perhaps it's not quite as easy as you think it is, and perhaps you're not as good at it as you think you are. Case in point, the comment you just made was not exactly the nicest I've read today.

- technical: E-mail is not a particularly good medium to convey emotions (in either way). For example someone with a naturally terse communication style may be perceived as harsh, while in person he's actually a very friendly bloke. And there's no way to communicate this impression back.

- cultural: Often what is quite polite in one culture may be seen as quite impolite or even rude in another. It's not just country vs. country, but even region vs. region (like for example East Coast vs. West Coast).

- personal: People in the community may know each other pretty well, in which case the communication style may be quite a bit more direct. But others may lack the context.

It's almost impossible to get it right all the time, without resorting to entirely mechanical corporate communication style. Which is not fut at all.

Of course, this does not mean there are no truly harsh / rude / WTF posts (even on PostgreSQL lists). But I'd say most of the time it's not meant that way.

> Another example: NAMEDATALEN restricts every identifier to 63 bytes - a limit that causes frequent issues (more so now that we have partitioning) and also a problem for multi-lingual table names. It’s been proposed to increase this limit a few times. Every time the answer has been: abbreviate your table names or recompile your own version of Postgres.

I think if it were easy, it'd immediately be fixed, but there's a fair bit of complexity in fixing it nicely. For partially historical and partially good reasons object names are allocated with NAMEDATALEN space, even for shorter names. So just increasing it would further waste memory... We're going to have to fix this properly one of these days.

Agreeing that there is something worthy of fixing is a first step. It should have happened with this NFS patch and imo some other stuff. The considerations for how and when should be dear with separately.

But there were like multiple people agreeing that it needs to be changed. Including the first two responses that the thread got. And there were legitimate questions around how interrupts need to be handled, about errors ought to be signaled if writes partially succeed and everything. Do you really expect us to integrate patches without thinking about that? And then the author vanished...

Whoa! You made huge leap there. At what point was it suggested that patches be recklessly applied?

That didn't happen. Your quote actually suggests a reasonable progression and at no point is there any suggestion, implied or otherwise, that changes be integrated without due consideration.

Not irrationally dismissing criticism != abandoning sound design and development.

That's not how well run projects function.

Which is why people are not enthusiastic about changing it, when there are fairly simple workarounds (assuming keeping the names short is considered to be a workaround).

Very likely many years, or even never. People don't use large names because they like it, they always prefer small ones.

How much memory are we talking about?

Well, we don't have exactly a barrage of complaints about the current limit either.

> How much memory are we talking about?

Good question.

The thing is - it's not just about table names. NameData is used for any object name, so it affects pretty much any system catalog storing name. A simple grep on the repo says it affects about 40 catalogs (out of 80), including pg_attribute, pg_class, pg_operator, pg_proc, pg_type (which tend to be fairly large).

So the amount of additional memory may be quite significant, because all of this is cached in various places.

The impact of doubling NameData size would be quite a bit worse, though, thanks to doubling of chunk-size in allocset. At the moment it fits into a 128B chunk (so just ~16B wasted), but by doubling NameData to 128B the struct would suddenly be 176B, which requires 256B chunk (so 80B wasted). Yuck.

Well, but on-disk varlena data is included. pg_column_size() averages 144 bytes for pg_attribute on my system.

> The impact of doubling NameData size would be quite a bit worse, though, thanks to doubling of chunk-size in allocset. At the moment it fits into a 128B chunk (so just ~16B wasted), but by doubling NameData to 128B the struct would suddenly be 176B, which requires 256B chunk (so 80B wasted). Yuck.

I'm not sure that actually matters that much. Most attributes are allocated as part of TupleDescData, but that allocates all attributes together.

Sure, but I thought we're talking about in-memory stuff as you've been talking about tuple descriptors. I don't think the on-disk size matters all that much, TBH, it's likely just a tiny fraction of data stored in the cluster.

> I'm not sure that actually matters that much. Most attributes are allocated as part of TupleDescData, but that allocates all attributes together.

Ah. Good point.

I've seen pg_attribute take up very significant fractions of the database numerous times, so I do think the on-disk size can matter. And there's plenty places, e.g. catcache, where we store the full on-disk tuple (rather than just the fixed-length prefix); so the on-disk size is actually quite relevant for the in-memory bit too.

not just bias against change. while there are some very talented and friendly people in the pg community, there are a few bad actors that are openly hostile and aggressive, that feel that they must be part of every discussion. it gets worse when it is a change that they made that is causing an issue, as ego takes a front seat.

unfortunately, these few bad actors make dealing with the pg mailing lists in general very unpleasant, and have made myself (a popular extension maintainer) and others try to keep interaction to an absolute minimum. that's not good for the community.

I'm sure there were cases of inappropriate / rude communication, but AFAICS those were rare one-off incidents. While you're apparently talking about long-term and consistent behavior. So I wonder who you're talking about? I can't think of anyone who'd consistently behave like that - particularly not among senior community members.

my comment, which is based on the multiple interactions I've had with the community, stands as is: some fantastic people, and a few aggressive bad actors that spoil things.

(Putting tenant_id as a column was not an option because for each tenant, a third-party software was started that wanted to have its own DB.)

This is not unique to Postgres. I've seen this behavior on many development mailing lists (e.g. Mutt-dev).

The core team has also to prioritize, deal with already planned features, and shoot down tons of people with inane ideas as well (not just good ones).

After reading this, I have been wondering if the other requests/ideas are not startup ideas

If you look at https://wiki.postgresql.org/wiki/PostgreSQL_derived_database..., it's a pretty long list - some of the product are successful, some are dead. And then there are products adding some extra sauce on top of PostgreSQL (e.g. timescaleDB).