This URL is blocked by my company's network because of a certain substring in the URL lol
I remember us once giving a supplier access to our internal bug tracker for a collaborative project. They were unable to get to the “…/openissue” endpoint.
How Postgres stores data on disk – this one's a page turner
41–50 of 98 posts
Re: How Postgres stores data on disk – this one's a page turner
#42Why does closing the table of contents open the nav menu on mobile?
On mobile, it appears to open regardless of where you tap. This appears to be the culprit:
```const n = document.getElementById('nav-header');
document.addEventListener(
'click',
s => {
u.hidden ||
s.target === null ||
n === null ||
n.contains(s.target) ||
r()
}```
Re: How Postgres stores data on disk – this one's a page turner
#43If anyone is interested in contrasting this with InnoDB (MySQL’s default engine), Jeremy Cole has an outstanding blog series [0] going into incredible detail.
Re: How Postgres stores data on disk – this one's a page turner
#44This URL is blocked by my company's network because of a certain substring in the URL lol
What why ? Would people browse bigcocks.net unless it’s explicitly blocked? What about cox? Is „tube“ on a blocklist as well?
It is idiotic, yes. This feature is certainly outsourced to our mediocre IT contractor
Re: How Postgres stores data on disk – this one's a page turner
#45This URL is blocked by my company's network because of a certain substring in the URL lol
A classic case of the Scunthorpe problem: https://en.wikipedia.org/wiki/Scunthorpe_problem In this case the substring is part of the author's name. Such names are not at all uncommon.
I just saw something similar with a user on here dangsux...
Apparently might be Dang's UX and not against the Mod. ¯\_(ツ)_/¯
Re: How Postgres stores data on disk – this one's a page turner
#46Earlier quoted context omitted.
Was thinking the same thing when I saw those zeros in the checksum field. Perhaps the consequences are significant. Here's a benchmarking exercise I found: https://www-staging.commandprompt.com/uploads/images/Command... With a tidy summary: > Any application with a high shared buffers hit ratio: little difference. > Any application with a high ratio of reads/writes: little difference. > Data logging application with…
On my M1 mac "dd ... | cksum" takes 3 seconds while "dd | shasum" (sha1) takes 2 seconds. So cksum might not be the best tool for performance checking. There is CPU specific code in the PG source in src/include/storage/checksum_impl.h It is written as a plain nested loop in C. So performance is fully dependent on the compiler being able to parallelize or vectorize the code. I would not be surprised if manually writte…
Interesting. I guess M1 doesn't have the 'crc32' "acceleration" that is included in SSE4.2.
Re: How Postgres stores data on disk – this one's a page turner
#47This URL is blocked by my company's network because of a certain substring in the URL lol
My company also blocks it, but as phishing.
Re: How Postgres stores data on disk – this one's a page turner
#48A bit of curiosity: how did Postgres choose 8k pages? shouldn’t it be the FS page size to help with atomicity?
Historically there was no atomicity at 4k boundaries, just at 512 byte boundaries (sectors). That'd have been too limiting. Lowering the limit now would prove problematic due to the smaller row sizes/ lower number of columns.
Re: How Postgres stores data on disk – this one's a page turner
#49Earlier quoted context omitted.
Was thinking the same thing when I saw those zeros in the checksum field. Perhaps the consequences are significant. Here's a benchmarking exercise I found: https://www-staging.commandprompt.com/uploads/images/Command... With a tidy summary: > Any application with a high shared buffers hit ratio: little difference. > Any application with a high ratio of reads/writes: little difference. > Data logging application with…
On my M1 mac "dd ... | cksum" takes 3 seconds while "dd | shasum" (sha1) takes 2 seconds. So cksum might not be the best tool for performance checking. There is CPU specific code in the PG source in src/include/storage/checksum_impl.h It is written as a plain nested loop in C. So performance is fully dependent on the compiler being able to parallelize or vectorize the code. I would not be surprised if manually writte…
The bottleneck isn't at all the checksum computation itself. It's that to keep checksums valid we need to protect against the potential of torn pages even in cases where it doesn't matter without checksums (i.e. were just individual bits are flipped). That in turn means we need to WAL log changes we don't need to without checksums - which can be painful.