Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
anarazel
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
85 ms
·
901.
▲
by
anarazel
8y ago
> (Postgres, as an example, relies on the OS to buffer writes.) We don't really buffer writes via the OS that much, most of them are buffered in postgres' internal buffer cache. We even force the kernel's hand to write out
902.
▲
by
anarazel
8y ago
> Sybase ASE calls fsync() upon every commit Those are journal commits, not the commits that the piece you quote is talking about (actual data files).
903.
▲
by
anarazel
8y ago
Uh. We've five years of old versions to support. We're not going to backpatch the invasive stuff necessary to make DIO performant. And it'd not be the default anyway, as it requires more tuning. We are working on getting
904.
▲
by
anarazel
9y ago
> Postgres's per statement triggers don't let you capture the rows that are modified They do these days. Since 10 you can specify: REFERENCING { { OLD | NEW } TABLE [ AS ] transition_relation_name } [ ... ] ] in a FOR EA
905.
▲
by
anarazel
9y ago
Well, benmmurphy isn't talking about serializability (some correct ordering exists), but strict serializabilty (roughly: at least one correct ordering corresponds to wall clock order). PG does have the former, but not the latter.
906.
▲
by
anarazel
9y ago
No. It means that IF and only if, your storage is dying, you might learn about it later than you wish. In cases your storage is dying you are likely also going to observe problems that are outside of an fsync() not reporting an error when
907.
▲
by
anarazel
9y ago
You misunderstood me, sorry I should have been clearer. Some internals are shared between inheritance and declarative partitioning. For v10 most parts of the system (except for COPY) used the same partition exclusion logic for both forms of
908.
▲
by
anarazel
9y ago
The partition selection / pruning in 10 was not yet improved from older inheritance based "partitioning" (COPY might already have been optimized back then, not sure right now). It's looking different in v11.
909.
▲
by
anarazel
9y ago
> Yes, but it's much more cumbersome to navigate the thread compared to using an actual mail client. If web pages of mail archives could present an overview pane for navigating messages, it would go a long way to making them usable
910.
▲
by
anarazel
9y ago
> I didn't think an MVCC implementation could provide that level of isolation MVCC needs a bit of additional logic ontop to be serializable - "Serializable snapshot isolation" is a good keyword to search for - But it'
911.
▲
by
anarazel
9y ago
> It apparently doesn't present a threaded view like a mail/news client would Not the same as a mail client, but once you opened an individual email there's threaded structure. > and downloading the mbox file requires o
912.
▲
by
anarazel
9y ago
> (actually, I didn't completely give up, I just browsed the Github mirror, which was the only usable part of their version control). What makes our git own git repo unusable? https://git.postgresql.org/gitweb/
913.
▲
by
anarazel
9y ago
Postgres' archives aren't that bad. You can find things via $search_engine, view by time, thread view crosses months etc: https://www.postgresql.org/list/pgsql-hackers/
914.
▲
by
anarazel
9y ago
Transparent hugepages, not explicitly configured ones, right?
915.
▲
by
anarazel
9y ago
It doesn't really matter that much whether its 12, 16, 24 byte. The difference is that, given how postgres is doing it at the very least, can pass anything bigger than 8 byte (on 64bit arch), in general purpose registers. So function c
916.
▲
by
anarazel
9y ago
> One of Postgres' strengths is how easy it is to add custom types for specific use cases. I suspect that if you've got a special need for higher precision, how high will also be a more narrow use case (how wide of a type, wha
917.
▲
by
anarazel
9y ago
Yea. If we wanted similar size we'd loose a lot of range. And increasing size beyond the size that can commonly be held in general purpose registers would have noticeable performance impacts as well. Types bigger than that have to be p
918.
▲
by
anarazel
9y ago
I don't think that's a meaningful comparison. There's quite the difference between "The data can be readily returned from the database if you omit the NOT deleted clause." and "You can use forensic tools to get
919.
▲
by
anarazel
9y ago
> Postgres don't actually delete data until you a VACUUM occurs. FWIW, a large portion of cleanup happens on access. If the entire page will not be accessed until the next VACUUM that doesn't change anything, but in OLTP worklo
920.
▲
by
anarazel
9y ago
And by being considered feature complete and being pretty decent back then, it has held back the entire field for a generation.
921.
▲
by
anarazel
9y ago
> I know the RDS team has contributed some fixes and the like to Postgres, but I’m unsure of their overall significance Negligible.
922.
▲
by
anarazel
9y ago
Link to the (development version) docs https://www.postgresql.org/docs/devel/static/jit.html
923.
▲
by
anarazel
9y ago
> Oh, I see. Thanks for clarifying! You mentioned it was merged. Does this mean it'll land in stable soon? It has been merged into the master branch, which'll become PostgreSQL 11. First beta will be in a few weeks. Release is
924.
▲
by
anarazel
9y ago
> That said, it's important to note that this is unlikely to help much with most OLTP queries just looking up information quickly via indexed data. It'll definitely not help for that, at least for now. There's not yet any
925.
▲
by
anarazel
9y ago
> Does this actually improve the performance of most queries? "most queries" - probably not. By sheer number that's going to be OLTP queries, and there it doesn't help. You need analytics queries that take upwards of
926.
▲
by
anarazel
9y ago
> I've often wondered why queries weren't be compiled to native code to remove interpreter overhead. It's not entire queries that are JITed at this point, it's just a subset of the work. WHERE clauses are, but the log
927.
▲
by
anarazel
9y ago
This actually has been fully merged since (JIT compiled expressions (projections, aggregates, etc), tuple deforming, operator implementation inlining). There's a lot of further work to do however (caching, non-crappy code for expressio
928.
▲
by
anarazel
9y ago
Which is really annoying. Still getting calls, two+ years in, for the previous owner of my number. Including from medical providers.
929.
▲
by
anarazel
9y ago
With concurrency it's certainly reasonable to hit constraints in production. Another session deletes something, another inserts a row that attempt to reference the deleted row. Or you have multiple users registering with the same accou
930.
▲
Database constraints: The last line of defense
(citusdata.com)
87 points
by
anarazel
9y ago
|
101 comments
More ›