pgaddict

14 ms·

121.
by pgaddict 8y ago
IMHO there were other / more important reasons why MySQL was initially more successful.
122.
by pgaddict 8y ago
I'm sure some of them are. And Citus is not the only startup pushing PostgreSQL in a way the community did not want to. If you look at https://wiki.postgresql.org/wiki/PostgreSQL_derived_database... , it's a p
123.
by pgaddict 8y ago
I'm honestly curious who are those bad actors, and examples of such behavior. I'm not trolling you, I really am curious - because that does not match my experience with the community at all. I'm sure there were cases of inapp
124.
by pgaddict 8y ago
IMHO it's way more complicated than it seems, because of a mix of technical, cultural and personal reasons. - technical: E-mail is not a particularly good medium to convey emotions (in either way). For example someone with a naturally
125.
by pgaddict 8y ago
Isn't one of the difficulties the inability to decide when the I/O error is transient (e.g. running out of space with thin provisioning) vs. permanent (e.g. drive eaten by a velociraptor)? Also, isn't it possible to use multi
126.
by pgaddict 8y ago
Ugh. I don't know a single PostgreSQL committer with that attitude. Maybe my patches are too crap to be in that situation, not sure.
127.
by pgaddict 8y ago
> Well, but on-disk varlena data is included. pg_column_size() averages 144 bytes for pg_attribute on my system. Sure, but I thought we're talking about in-memory stuff as you've been talking about tuple descriptors. I don&#x27
128.
by pgaddict 8y ago
Is it ~140 bytes? pahole says it's 112 (without CATALOG_VARLEN). 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 ~1
129.
by pgaddict 8y ago
I don't think we disagree, actually. Yes - from a purely technical point of view, DIO is superior in various ways. It allows tuning to specific I/O patterns, etc. But it's also quite laborious to get right - not only does it
130.
by pgaddict 8y ago
No. Kernels before 4.13 may or may not report the fsync error correctly, depending on various conditions. There are more details in the talk [1] I posted earlier, and in the LWN articles related to this issue. [1] https://www.you
131.
by pgaddict 8y ago
> Review in the PostgreSQL community does tend to be on the "harsh" side. Can you share an example of a review that you consider harsh? (feel free to share privately, I'm simply interested in what you consider harsh) I adm
132.
by pgaddict 8y ago
> Very likely many years, or even never. People don't use large names because they like it, they always prefer small ones. Well, we don't have exactly a barrage of complaints about the current limit either. > How much memory
133.
by pgaddict 8y ago
Yeah, which is one of the reasons PostgreSQL went with buffered I/O, not to have to deal with this complexity. And it served us pretty well over time, I think.
134.
by pgaddict 8y ago
Interestingly enough, such issues are becoming more common. It's not just about devices being less reliable, but e.g. thin provisioning being used more widely etc.
135.
by pgaddict 8y ago
I'm pretty sure it does affect any database/application relying on buffered I/O. Even if you use the fsync() interface correctly, you're still affected by the bugs in error reporting.
136.
by pgaddict 8y ago
I'm not sure. It's easy to blame other layers for not behaving the way you want/expect, but I admit there are valid reasons why it behaves the way it does and not the way you imagine. The PostgreSQL fsync thread started with
137.
by pgaddict 8y ago
There have been bugs involved on both sides. On the kernel side the error reporting was not working reliably in some cases (see [1] for details), so the application using fsync may not actually get the error at all. Hard to handle an error
138.
by pgaddict 8y ago
I don't think I've encountered "asshole reviewer" in postgres community, but maybe my "pain threshold" is just higher than yours. More often than not it's a valid disagreement about technical matters.
139.
by pgaddict 8y ago
Which of the messages on the thread do you consider as bikeshedding? I personally don't see any - that's not to say I agree with everything said on the thread, but overall it seems like a reasonable discussion. IMHO it's a bi
140.
by pgaddict 8y ago
Well, that's the thing - changing NAMEDATALEN is a seemingly small change, but it'll require much more work than just increasing the value. Increasing the value does not seem like a great option, because (a) how long before people
141.
by pgaddict 8y ago
I'm sure some of the difference (25M vs. 1.3M) can be attributed to code for Oracle features missing in PostgreSQL. But a significant part of it is due to careful development process mercilessly eliminating duplicate and unnecessary co
142.
by pgaddict 8y ago
The "extreme hostility" is not against alternative development/licensing models, but against doing X but saying it's Y. It's obviously everyone's choice to pick whatever license / licensing model you want.
143.
by pgaddict 8y ago
It's not like every contributor (or even committer) understands all parts of the code base - I certainly don't. People usually start by writing external code (e.g. by writing extensions in C), learn the code style and basic const
144.
by pgaddict 8y ago
Oh! I honestly haven't realized we already have release notes for 12 ...
145.
by pgaddict 8y ago
Yeah, DROP PARTITION is definitely going to be much more efficient than DELETE + cleanup. No doubt about that. Not sure what postgresql.conf tuning you've tried, but in general we recommend making autovacuum more frequent, but performi
146.
by pgaddict 8y ago
Well, stated intent is great, but it's not the same as certainty. Don't get me wrong - I hope we end up enabling it in 12. But underpromise + overdeliver ;-) BTW what's "12 notesnotes"?
147.
by pgaddict 8y ago
> > Generally speaking yes, but it's not clear when exactly that will happen (if at all). > > It's still enabled by default in 12/master. I'd expect it to stay that way. But reports for v11 will obviously i
148.
by pgaddict 8y ago
Who says you need to feed it directly to the replica. Logical replication provides infrastructure for decoding changes, and you may fetch it any way you want / how often you want / feed it wherever you want (file, another database
149.
by pgaddict 8y ago
You need to accumulate the data somewhere. If you don't fetch if from the node, it has to accumulate there. Custom sync protocol does not eliminate this.
150.
by pgaddict 8y ago
Yeah, we're not particularly good at those out of the box. 1) Horizontal scaling: In some cases it's doable using streaming replication, but it depends if you need to scale reads or writes. Or if you need distributed queries. Ther

More ›