So, why would you want unreliable tables? The truth is that, under some specific circumstances, you don't care that much. Furthermore, it is also used for replication by Compose for a failover, but if you make a table unlogged when you create it, writes to it will never be copied to the secondary server, so if a failover happens, the secondary server will always come up with completely empty tables. However, the Write-Ahead Logging ( WAL) system is a key component of what makes Postgres reliable. What makes writing a lot faster is that the logging daemon is disabled entirely for the table that is flagged as UNLOGGED. Any indexes created on an unlogged table are automatically unlogged as well. The contents of an unlogged table are also not replicated to standby servers.
However, they are not crash-safe: an unlogged table is automatically truncated after a crash or unclean shutdown. (.) Data written to unlogged tables is not written to the write-ahead log, which makes them considerably faster than ordinary tables. Unlogged tables were introduced in PostgreSQL 9.1 in 2011. If data consistency after a server crash is not an issue, or you’re just gonna deal with a disposable table that needs that extra boost for writing - then unlogged tables are for you.
Do you want to shed light on a favorite feature in your preferred database? Why not write a short "Addon" for Write Stuff?
#Postgresql alter table how to
Lucero Del Alba takes a look at how to get better performance with PostgreSQL, as long as you aren't too worried about replication and persistence. In the first "Addon" article of this cycle of Compose's Write Stuff, Faster Performance with Unlogged Tables in PostgreSQL writestuff performance postgresql Free 30 Day Trial
0 kommentar(er)
