Standardní implementace ispell slovníků v PostgreSQL má bohužel několik nevýhod co se CPU a paměti týká. Napsal jsem extension která umožňuje slovníky inicializovat jen jednou a sdílet je mezi spojeními.
Jaký dopad na výkon má přesun transakčního logu nebo indexů na samostatný disk? Jak výsledek závisí na typu workloadu (OLTP vs. DWH) a na typu disku (HDD vs. SSD)?
A comparison of different solutions for full-text search in web applications using PostgreSQL and other technology. Presented at the PostgreSQL Conference West, in Seattle, October 2009.
Pokusil jsem se dát dohromady základní přehled častých chyb, na které člověk v různých webových aplikacích narazí.
Zároveň také otevírám téma striktnosti práce s typy a hodnotami, které se často ignoruje, ale každá opravdu solidní aplikace jej musí řešit.
Jaký dopad na výkon má přesun transakčního logu nebo indexů na samostatný disk? Jak výsledek závisí na typu workloadu (OLTP vs. DWH) a na typu disku (HDD vs. SSD)?
A comparison of different solutions for full-text search in web applications using PostgreSQL and other technology. Presented at the PostgreSQL Conference West, in Seattle, October 2009.
Pokusil jsem se dát dohromady základní přehled častých chyb, na které člověk v různých webových aplikacích narazí.
Zároveň také otevírám téma striktnosti práce s typy a hodnotami, které se často ignoruje, ale každá opravdu solidní aplikace jej musí řešit.
Má smysl používat Perl 6? Postmoderní jazyk, lepicí páska, která drží pohromadě celý internet, TIMTOWTDI, Camelia a děti s poruchou autistického spektra.
node.js: zápisky z fronty (Battle guide to node.js)almadcz
[czech] V Apiary používáme node.js v produkci už přes rok.
Proč se zamyslet nad tím, zda ho chcete? A na co se připravit a na co si dát pozor, pokud se do toho pustíte?
Přehled variant databázové replikace (master-slave vs. master-master, physical vs. logical) a jejich pro a proti. Krátká historie replikace v PostgreSQL s přehled nástrojů které dnes máme k dispozici (slony-I, pgpool-II, Londiste a Bucardo). A nakonec stručné srovnání s replikací ve dvou populárních databázích (MySQL a Oracle).
CoffeeScript je jazyk, který se kompiluje do čitelného JavaScriptu. Zpřehledňuje a zjednodušuje zápis často používaných věcí při zachování kompatibility s "obyčejným" JavaScriptem. Prezentace se pokouší jej stručně představit.
CREATE STATISTICS - What is it for? (PostgresLondon)Tomas Vondra
CREATE STATISTICS command was introduced in PostgreSQL 10, and improved in PostgreSQL 12. Let's see what queries it's meant to improve and how it works.
Let's discuss the various sources of data corruption in databases (and in PostgreSQL in general) - cosmic rays, storage, bugs in the OS, database or application. I'll share some general observations about those various sources, and also some recommendations how to detect those issues in PostgreSQL (data checksums, ...) and how to deal with them.
The document discusses different approaches to storing sensitive data like credit card numbers in a database. It compares using full-disk encryption versus application-level encryption. Full-disk encryption protects against theft but prevents indexing and queries on encrypted fields. Application-level encryption requires decrypting and re-encrypting all data, moving processing to the application. The document proposes a solution of using a separate trusted component that can compare encrypted values to enable indexing and aggregation while keeping data encrypted in the database.
PostgreSQL performance improvements in 9.5 and 9.6Tomas Vondra
The document summarizes performance improvements in PostgreSQL versions 9.5 and 9.6. Some key improvements discussed include optimizations to sorting, hash joins, BRIN indexes, parallel query processing, aggregate functions, checkpoints, and freezing. Performance tests on sorting, hash joins, and parallel queries show significant speedups from these changes, such as faster sorting times and better scalability with parallel queries.
PostgreSQL na EXT4, XFS, BTRFS a ZFS / FOSDEM PgDay 2016Tomas Vondra
The document provides an overview of different file systems for PostgreSQL including EXT3/4, XFS, BTRFS and ZFS. It discusses the evolution and improvements made to EXT3/4 and XFS over time to address scalability, bugs and new storage technologies like SSDs. BTRFS and ZFS are described as designed for large data volumes and built-in features like snapshots and checksums but BTRFS is still considered experimental. Benchmark results show ZFS and optimized EXT4/XFS performing best and BTRFS performance significantly reduced due to copy-on-write. The conclusion recommends EXT4/XFS for traditional needs and ZFS for advanced features, avoiding BTRFS.
PostgreSQL on EXT4, XFS, BTRFS and ZFSTomas Vondra
One of the most common question I'm asked by users and customer about configuring a Linux-based system for PostgreSQL is "What file fystem should I use to get the best performance?" Sadly, most of the recommendations is based on obsolete "common knowledge" passed from generation to generation. But in recent years the file systems improved a lot - we've seen both evolution of established file systems (EXT family, XFS, ...) and revolution in the form of BTRFS, ZFS or F2FS. And of course new kinds of hardware (SSDs) which certainly impacts the design of a file system.
Performance improvements in PostgreSQL 9.5 and beyondTomas Vondra
This document discusses several performance improvements made in PostgreSQL versions 9.5 and beyond. Some key improvements discussed include:
- Faster sorting through allowing sorting by inlined functions, abbreviated keys for VARCHAR/TEXT/NUMERIC, and Sort Support benefits.
- Improved hash joins through reduced palloc overhead, smaller NTUP_PER_BUCKET, and dynamically resizing the hash table.
- Index improvements like avoiding index tuple copying, GiST and bitmap index scan optimizations, and block range tracking in BRIN indexes.
- Aggregate functions see speedups through using 128-bit integers for internal state instead of NUMERIC in some cases.
- Other optimizations affect PL/pgSQL performance,
The document summarizes performance benchmarks comparing PostgreSQL versions from 7.4 to the latest version. The benchmarks show significant performance improvements across different workloads over time, including:
- Up to 6x faster transaction processing rates in pgbench
- Much better scalability to multiple cores and clients
- 6x faster query times for TPC-DS data warehouse benchmark
- Over 10x speedup for some full text search queries in latest version
The benchmarks demonstrate that PostgreSQL has become dramatically faster and more scalable over the past 10+ years, while also using less disk space and memory.
Stručný úvod do čtení explain planu - seznámení s principem jak databáze vybírá postup vyhodnocení dotazu, na jaké základní operace v něm můžeme narazit (varianty čtení tabulek a joinů). Zejména se ale podíváme na to jak identifikovat problematická místa v exekučním plánu, v čem může být příčina a jak ji odstranit.
Má smysl používat Perl 6? Postmoderní jazyk, lepicí páska, která drží pohromadě celý internet, TIMTOWTDI, Camelia a děti s poruchou autistického spektra.
node.js: zápisky z fronty (Battle guide to node.js)almadcz
[czech] V Apiary používáme node.js v produkci už přes rok.
Proč se zamyslet nad tím, zda ho chcete? A na co se připravit a na co si dát pozor, pokud se do toho pustíte?
Přehled variant databázové replikace (master-slave vs. master-master, physical vs. logical) a jejich pro a proti. Krátká historie replikace v PostgreSQL s přehled nástrojů které dnes máme k dispozici (slony-I, pgpool-II, Londiste a Bucardo). A nakonec stručné srovnání s replikací ve dvou populárních databázích (MySQL a Oracle).
CoffeeScript je jazyk, který se kompiluje do čitelného JavaScriptu. Zpřehledňuje a zjednodušuje zápis často používaných věcí při zachování kompatibility s "obyčejným" JavaScriptem. Prezentace se pokouší jej stručně představit.
CREATE STATISTICS - What is it for? (PostgresLondon)Tomas Vondra
CREATE STATISTICS command was introduced in PostgreSQL 10, and improved in PostgreSQL 12. Let's see what queries it's meant to improve and how it works.
Let's discuss the various sources of data corruption in databases (and in PostgreSQL in general) - cosmic rays, storage, bugs in the OS, database or application. I'll share some general observations about those various sources, and also some recommendations how to detect those issues in PostgreSQL (data checksums, ...) and how to deal with them.
The document discusses different approaches to storing sensitive data like credit card numbers in a database. It compares using full-disk encryption versus application-level encryption. Full-disk encryption protects against theft but prevents indexing and queries on encrypted fields. Application-level encryption requires decrypting and re-encrypting all data, moving processing to the application. The document proposes a solution of using a separate trusted component that can compare encrypted values to enable indexing and aggregation while keeping data encrypted in the database.
PostgreSQL performance improvements in 9.5 and 9.6Tomas Vondra
The document summarizes performance improvements in PostgreSQL versions 9.5 and 9.6. Some key improvements discussed include optimizations to sorting, hash joins, BRIN indexes, parallel query processing, aggregate functions, checkpoints, and freezing. Performance tests on sorting, hash joins, and parallel queries show significant speedups from these changes, such as faster sorting times and better scalability with parallel queries.
PostgreSQL na EXT4, XFS, BTRFS a ZFS / FOSDEM PgDay 2016Tomas Vondra
The document provides an overview of different file systems for PostgreSQL including EXT3/4, XFS, BTRFS and ZFS. It discusses the evolution and improvements made to EXT3/4 and XFS over time to address scalability, bugs and new storage technologies like SSDs. BTRFS and ZFS are described as designed for large data volumes and built-in features like snapshots and checksums but BTRFS is still considered experimental. Benchmark results show ZFS and optimized EXT4/XFS performing best and BTRFS performance significantly reduced due to copy-on-write. The conclusion recommends EXT4/XFS for traditional needs and ZFS for advanced features, avoiding BTRFS.
PostgreSQL on EXT4, XFS, BTRFS and ZFSTomas Vondra
One of the most common question I'm asked by users and customer about configuring a Linux-based system for PostgreSQL is "What file fystem should I use to get the best performance?" Sadly, most of the recommendations is based on obsolete "common knowledge" passed from generation to generation. But in recent years the file systems improved a lot - we've seen both evolution of established file systems (EXT family, XFS, ...) and revolution in the form of BTRFS, ZFS or F2FS. And of course new kinds of hardware (SSDs) which certainly impacts the design of a file system.
Performance improvements in PostgreSQL 9.5 and beyondTomas Vondra
This document discusses several performance improvements made in PostgreSQL versions 9.5 and beyond. Some key improvements discussed include:
- Faster sorting through allowing sorting by inlined functions, abbreviated keys for VARCHAR/TEXT/NUMERIC, and Sort Support benefits.
- Improved hash joins through reduced palloc overhead, smaller NTUP_PER_BUCKET, and dynamically resizing the hash table.
- Index improvements like avoiding index tuple copying, GiST and bitmap index scan optimizations, and block range tracking in BRIN indexes.
- Aggregate functions see speedups through using 128-bit integers for internal state instead of NUMERIC in some cases.
- Other optimizations affect PL/pgSQL performance,
The document summarizes performance benchmarks comparing PostgreSQL versions from 7.4 to the latest version. The benchmarks show significant performance improvements across different workloads over time, including:
- Up to 6x faster transaction processing rates in pgbench
- Much better scalability to multiple cores and clients
- 6x faster query times for TPC-DS data warehouse benchmark
- Over 10x speedup for some full text search queries in latest version
The benchmarks demonstrate that PostgreSQL has become dramatically faster and more scalable over the past 10+ years, while also using less disk space and memory.
Stručný úvod do čtení explain planu - seznámení s principem jak databáze vybírá postup vyhodnocení dotazu, na jaké základní operace v něm můžeme narazit (varianty čtení tabulek a joinů). Zejména se ale podíváme na to jak identifikovat problematická místa v exekučním plánu, v čem může být příčina a jak ji odstranit.
Prezentace připravená pro konferenci Prague PostgreSQL Developers' Day 2010. Hlavním tématem je monitoring výkonu PostgreSQL databázového serveru, nástrojů které k tomu lze použít, atd. Na začátku jsou představeny základní pojmy (např. co je to snapshot), a poté je předvedeno několik užitečných nástrojů (jeden z nich vyvíjím já).
6. ispell
● založeno na slovníku
● sada pravidel (skloňování, časování)
● slovník (slovo + jak skloňovat)
7. ispell
● založeno na slovníku
● sada pravidel (skloňování, časování)
● slovník (slovo + jak skloňovat)
● tři problémy
● per connection
● inicializace
● zabírá paměť
● …
Actually...It's Not Okay
8. inicializace
● slovník se musí načíst a naparsovat
● CPU, I/O
● ~ přes vteřinu, podle systému
● … nic moc :-(
● standardní řešení
● connection pool
● … ale nic není tak růžové
9. CPU vs. RAM
● krátká vs. dlouhá spojení
● oslíkovo dilema
● krátká spojení – opakovaná inicializace (CPU)
● dlouhá spojení – kopie statických dat (RAM)
● 25 connections + 2 slovníky (cs + cs_ascii)
500 MB
● standardně víc connections (100 ?)
10. ispell vs. RAM
● virtualizovaná prostředí
● VPS
● sdílené servery
Tam všude je (často) nedostatek RAM.
12. shared_ispell
● načítá slovníky do sdílené paměti
● jednorázová inicializace
● každý slovník uložen jen jednou
● používá se stejně jako obyčejný ispell
● paměť je nutno vyhradit předem
● ne všechny slovníky
13. shared_ispell API
● info o paměti
● shared_ispell_mem_used()
● shared_ispell_mem_available()
● slovníky / stop words
● shared_ispell_dicts()
● shared_ispell_stoplists()
● shared_ispell_reset()