{"id":11974,"date":"2018-11-10T11:19:52","date_gmt":"2018-11-10T10:19:52","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/an-index-only-scan-in-postgresql-is-not-always-index-only\/"},"modified":"2018-11-10T11:19:52","modified_gmt":"2018-11-10T10:19:52","slug":"an-index-only-scan-in-postgresql-is-not-always-index-only","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/an-index-only-scan-in-postgresql-is-not-always-index-only\/","title":{"rendered":"An index only scan in PostgreSQL is not always index only"},"content":{"rendered":"

PostgreSQL supports index only scans<\/a> since version 9.2 which was released in September 2013. The purpose of an index only scan is to fetch all the required values entirely from the index without visiting the table (the heap) at all. Of course that can speed up a query because avoiding to touch the heap, means reading less data and reading less data is obviously faster than reading more data. So index only scans are a good thing but unfortunately it does not always mean that the heap is not touched.<\/p>\n

<\/p>\n

As always, lets start by creating a sample table and populate it with some data:<\/p>\n

\npostgres=# create table t1 ( a int, b int, c int );\nCREATE TABLE\npostgres=# insert into t1 select a.*,a.*,a.* from generate_series(1,1000000) a;\nINSERT 0 1000000\npostgres=# d+ t1\n                                    Table \"public.t1\"\n Column |  Type   | Collation | Nullable | Default | Storage | Stats target | Description \n--------+---------+-----------+----------+---------+---------+--------------+-------------\n a      | integer |           |          |         | plain   |              | \n b      | integer |           |          |         | plain   |              | \n c      | integer |           |          |         | plain   |              | \n<\/pre>\n
Without any index a query like the following one needs to read the whole table for getting the result:<\/p>\n
\npostgres=# explain (analyze,buffers,costs off) select a from t1 where b = 5;\n                                 QUERY PLAN                                 \n----------------------------------------------------------------------------\n Gather (actual time=2.187..158.023 rows=1 loops=1)\n   Workers Planned: 2\n   Workers Launched: 2\n   Buffers: shared hit=5406\n   ->  Parallel Seq Scan on t1 (actual time=68.645..119.828 rows=0 loops=3)\n         Filter: (b = 5)\n         Rows Removed by Filter: 333333\n         Buffers: shared hit=5406\n Planning time: 0.209 ms\n Execution time: 158.079 ms\n(10 rows)\n<\/pre>\n
In this case PostgreSQL decides to do a parallel sequential scan which is fine. The only other option would be to do a serial sequential scan as we do not have any indexes on that table. What people usually do in such cases is to create an index like this one:<\/p>\n
\npostgres=# create index i1 on t1(b);\nCREATE INDEX\npostgres=# d t1\n                 Table \"public.t1\"\n Column |  Type   | Collation | Nullable | Default \n--------+---------+-----------+----------+---------\n a      | integer |           |          | \n b      | integer |           |          | \n c      | integer |           |          | \nIndexes:\n    \"i1\" btree (b)\n<\/pre>\n
Having that index in place PostgreSQL can use it to return the results faster:<\/p>\n
\npostgres=# explain (analyze,buffers,costs off) select a from t1 where b = 5;\n                             QUERY PLAN                              \n---------------------------------------------------------------------\n Index Scan using i1 on t1 (actual time=0.035..0.037 rows=1 loops=1)\n   Index Cond: (b = 5)\n   Buffers: shared hit=4\n Planning time: 0.174 ms\n Execution time: 0.081 ms\n(5 rows)\n<\/pre>\n
As you can see above the index is used but PostgreSQL will still have to visit the heap for getting the value of “a”. We can improve that even further by creating an index that contains all the information we need to satisfy the query:<\/p>\n
\npostgres=# create index i2 on t1 (b,a);\nCREATE INDEX\npostgres=# d t1\n                 Table \"public.t1\"\n Column |  Type   | Collation | Nullable | Default \n--------+---------+-----------+----------+---------\n a      | integer |           |          | \n b      | integer |           |          | \n c      | integer |           |          | \nIndexes:\n    \"i1\" btree (b)\n    \"i2\" btree (b, a)\n<\/pre>\n
What will happen now is, that PostgreSQL will switch to an index only scan:<\/p>\n
\npostgres=# explain (analyze,buffers,costs off) select a from t1 where b = 5;\n                                QUERY PLAN                                \n--------------------------------------------------------------------------\n Index Only Scan using i2 on t1 (actual time=0.111..0.113 rows=1 loops=1)\n   Index Cond: (b = 5)\n   Heap Fetches: 1\n   Buffers: shared hit=1 read=3\n Planning time: 0.515 ms\n Execution time: 0.161 ms\n(6 rows)\n<\/pre>\n
But: There is still a fetch from the heap. Why that? For answering that, lets list the files on disk for that table:<\/p>\n
\npostgres=# select pg_relation_filepath('t1');\n pg_relation_filepath \n----------------------\n base\/34013\/34082\n(1 row)\n\npostgres=# ! ls -l $PGDATA\/base\/34013\/34082*\n-rw-------. 1 postgres postgres 44285952 Nov  8 04:51 \/u02\/pgdata\/10\/PG103\/base\/34013\/34082\n-rw-------. 1 postgres postgres    32768 Nov  8 04:46 \/u02\/pgdata\/10\/PG103\/base\/34013\/34082_fsm\n<\/pre>\n
… and here we go: The table has a free space map<\/a> but the visibility map<\/a> is not yet there. Without the visibility map PostgreSQL can not know if all the rows in that page are visible to all current transactions and therefore has to visit the heap to get that information. As soon as we create the visibility map:<\/p>\n
\npostgres=# vacuum t1;\nVACUUM\npostgres=# ! ls -l $PGDATA\/base\/34013\/34082*\n-rw-------. 1 postgres postgres 44285952 Nov  8 04:51 \/u02\/pgdata\/10\/PG103\/base\/34013\/34082\n-rw-------. 1 postgres postgres    32768 Nov  8 04:46 \/u02\/pgdata\/10\/PG103\/base\/34013\/34082_fsm\n-rw-------. 1 postgres postgres     8192 Nov  8 07:18 \/u02\/pgdata\/10\/PG103\/base\/34013\/34082_vm\npostgres=# explain (analyze,buffers,costs off) select a from t1 where b = 5;\n                                QUERY PLAN                                \n--------------------------------------------------------------------------\n Index Only Scan using i2 on t1 (actual time=0.052..0.054 rows=1 loops=1)\n   Index Cond: (b = 5)\n   Heap Fetches: 0\n   Buffers: shared hit=4\n Planning time: 0.446 ms\n Execution time: 0.106 ms\n(6 rows)\n<\/pre>\n
… the fetch from the heap is gone and we have a real index only scan (although the visibility map is always scanned). To demonstrate that in more detail lets get the physical location of the row we want to read:<\/p>\n
>\npostgres=# select ctid,* from t1 where b=5;\n ctid  | a | b | c \n-------+---+---+---\n (0,5) | 5 | 5 | 5\n(1 row)\n<\/pre>\n
Now we know that the row is in block 0 and it is the 5th row in that block. Let’s check, for that block, if all rows are visible to all current transactions:<\/p>\n
\npostgres=# create extension pg_visibility;\nCREATE EXTENSION\npostgres=# select pg_visibility_map('t1'::regclass, 0);\n pg_visibility_map \n-------------------\n (t,f)\n(1 row)\n<\/pre>\n
Yes, they are (the first “t”, which is true, means all visible<\/a>). What happens when we update the row in a second session?<\/p>\n
\npostgres=# update t1 set a=8 where b=5;\nUPDATE 1\n<\/pre>\n
Do we still get a “true” when we ask if all rows in that block are visible to all transactions?<\/p>\n
\npostgres=# select pg_visibility_map('t1'::regclass, 0);\n pg_visibility_map \n-------------------\n (f,f)\n(1 row)\n<\/pre>\n
No, and that means two things: First of all a modification to a page clears the bit in the visibility map. The second consequence is, that our index only scan will need to visit the heap again:<\/p>\n
\npostgres=# explain (analyze,buffers,costs off) select a from t1 where b = 5;\n                                QUERY PLAN                                \n--------------------------------------------------------------------------\n Index Only Scan using i2 on t1 (actual time=0.263..0.267 rows=1 loops=1)\n   Index Cond: (b = 5)\n   Heap Fetches: 2\n   Buffers: shared hit=6 dirtied=3\n Planning time: 0.205 ms\n Execution time: 0.328 ms\n(6 rows)\n<\/pre>\n
The question now is: Why two heap fetches? First of all every update in PostgreSQL creates a new row:<\/p>\n
\npostgres=# select ctid,* from t1 where b=5;\n   ctid    | a | b | c \n-----------+---+---+---\n (5405,76) | 8 | 5 | 5\n(1 row)\n<\/pre>\n
Our row is now in a new block (and even if if would be in the same block it would be at another location in the block) and that of course also affects the index entry which points to that row. The index still points to the old version of the row and there is the pointer to the current version which means two heap fetches (when you update a column that is not part of the index, that is called a hot update, more on that in another post). For the next execution we see one heap fetch again:<\/p>\n
\npostgres=# explain (analyze,buffers,costs off) select a from t1 where b = 5;\n                                QUERY PLAN                                \n--------------------------------------------------------------------------\n Index Only Scan using i2 on t1 (actual time=0.022..0.023 rows=1 loops=1)\n   Index Cond: (b = 5)\n   Heap Fetches: 1\n   Buffers: shared hit=5\n Planning time: 0.093 ms\n Execution time: 0.047 ms\n(6 rows)\n<\/pre>\n
Not sure why only one, at the moment, but I’ll update this blog once I have more information.<\/p>\n
What you need to remember is, that an index only scan is not always index only. Depending on how many modifications are happening on that table, it might well be that PostgreSQL must visit the heap quite a lot of times which of course slows down things. For tables where most of the blocks are static an index only scan is great.<\/p>\n","protected":false},"excerpt":{"rendered":"
PostgreSQL supports index only scans since version 9.2 which was released in September 2013. The purpose of an index only scan is to fetch all the required values entirely from the index without visiting the table (the heap) at all. Of course that can speed up a query because avoiding to touch the heap, means […]<\/p>\n","protected":false},"author":29,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[229],"tags":[77],"type_dbi":[],"class_list":["post-11974","post","type-post","status-publish","format-standard","hentry","category-database-administration-monitoring","tag-postgresql"],"acf":[],"yoast_head":"\nAn index only scan in PostgreSQL is not always index only - dbi Blog<\/title>\n<meta name=\"description\" content=\"An index only scan in PostgreSQL is not always index only\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/an-index-only-scan-in-postgresql-is-not-always-index-only\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"An index only scan in PostgreSQL is not always index only\" \/>\n<meta property=\"og:description\" content=\"An index only scan in PostgreSQL is not always index only\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/an-index-only-scan-in-postgresql-is-not-always-index-only\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2018-11-10T10:19:52+00:00\" \/>\n<meta name=\"author\" content=\"Daniel Westermann\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@westermanndanie\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Daniel Westermann\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"6 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-index-only-scan-in-postgresql-is-not-always-index-only\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-index-only-scan-in-postgresql-is-not-always-index-only\\\/\"},\"author\":{\"name\":\"Daniel Westermann\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/8d08e9bd996a89bd75c0286cbabf3c66\"},\"headline\":\"An index only scan in PostgreSQL is not always index only\",\"datePublished\":\"2018-11-10T10:19:52+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-index-only-scan-in-postgresql-is-not-always-index-only\\\/\"},\"wordCount\":692,\"commentCount\":0,\"keywords\":[\"PostgreSQL\"],\"articleSection\":[\"Database Administration & Monitoring\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-index-only-scan-in-postgresql-is-not-always-index-only\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-index-only-scan-in-postgresql-is-not-always-index-only\\\/\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-index-only-scan-in-postgresql-is-not-always-index-only\\\/\",\"name\":\"An index only scan in PostgreSQL is not always index only - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\"},\"datePublished\":\"2018-11-10T10:19:52+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/8d08e9bd996a89bd75c0286cbabf3c66\"},\"description\":\"An index only scan in PostgreSQL is not always index only\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-index-only-scan-in-postgresql-is-not-always-index-only\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-index-only-scan-in-postgresql-is-not-always-index-only\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-index-only-scan-in-postgresql-is-not-always-index-only\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"An index only scan in PostgreSQL is not always index only\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/8d08e9bd996a89bd75c0286cbabf3c66\",\"name\":\"Daniel Westermann\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g\",\"caption\":\"Daniel Westermann\"},\"description\":\"Daniel Westermann is Principal Consultant and Technology Leader Open Infrastructure at dbi services. He has more than 15 years of experience in management, engineering and optimization of databases and infrastructures, especially on Oracle and PostgreSQL. Since the beginning of his career, he has specialized in Oracle Technologies and is Oracle Certified Professional 12c and Oracle Certified Expert RAC\\\/GridInfra. Over time, Daniel has become increasingly interested in open source technologies, becoming \u201cTechnology Leader Open Infrastructure\u201d and PostgreSQL expert. \u00a0Based on community or EnterpriseDB tools, he develops and installs complex high available solutions with PostgreSQL. He is also a certified PostgreSQL Plus 9.0 Professional and a Postgres Advanced Server 9.4 Professional. He is a regular speaker at PostgreSQL conferences in Switzerland and Europe. Today Daniel is also supporting our customers on AWS services such as AWS RDS, database migrations into the cloud, EC2 and automated infrastructure management with AWS SSM (System Manager). He is a certified AWS Solutions Architect Professional. Prior to dbi services, Daniel was Management System Engineer at LC SYSTEMS-Engineering AG in Basel. Before that, he worked as Oracle Developper &\u00a0Project Manager at Delta Energy Solutions AG in Basel (today Powel AG). Daniel holds a diploma in Business Informatics (DHBW, Germany). His branch-related experience mainly covers the pharma industry, the financial sector, energy, lottery and telecommunications.\",\"sameAs\":[\"https:\\\/\\\/x.com\\\/westermanndanie\"],\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/author\\\/daniel-westermann\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"An index only scan in PostgreSQL is not always index only - dbi Blog","description":"An index only scan in PostgreSQL is not always index only","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/an-index-only-scan-in-postgresql-is-not-always-index-only\/","og_locale":"en_US","og_type":"article","og_title":"An index only scan in PostgreSQL is not always index only","og_description":"An index only scan in PostgreSQL is not always index only","og_url":"https:\/\/www.dbi-services.com\/blog\/an-index-only-scan-in-postgresql-is-not-always-index-only\/","og_site_name":"dbi Blog","article_published_time":"2018-11-10T10:19:52+00:00","author":"Daniel Westermann","twitter_card":"summary_large_image","twitter_creator":"@westermanndanie","twitter_misc":{"Written by":"Daniel Westermann","Est. reading time":"6 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/an-index-only-scan-in-postgresql-is-not-always-index-only\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/an-index-only-scan-in-postgresql-is-not-always-index-only\/"},"author":{"name":"Daniel Westermann","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66"},"headline":"An index only scan in PostgreSQL is not always index only","datePublished":"2018-11-10T10:19:52+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/an-index-only-scan-in-postgresql-is-not-always-index-only\/"},"wordCount":692,"commentCount":0,"keywords":["PostgreSQL"],"articleSection":["Database Administration & Monitoring"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/an-index-only-scan-in-postgresql-is-not-always-index-only\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/an-index-only-scan-in-postgresql-is-not-always-index-only\/","url":"https:\/\/www.dbi-services.com\/blog\/an-index-only-scan-in-postgresql-is-not-always-index-only\/","name":"An index only scan in PostgreSQL is not always index only - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2018-11-10T10:19:52+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66"},"description":"An index only scan in PostgreSQL is not always index only","breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/an-index-only-scan-in-postgresql-is-not-always-index-only\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/an-index-only-scan-in-postgresql-is-not-always-index-only\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/an-index-only-scan-in-postgresql-is-not-always-index-only\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"An index only scan in PostgreSQL is not always index only"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66","name":"Daniel Westermann","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g","caption":"Daniel Westermann"},"description":"Daniel Westermann is Principal Consultant and Technology Leader Open Infrastructure at dbi services. He has more than 15 years of experience in management, engineering and optimization of databases and infrastructures, especially on Oracle and PostgreSQL. Since the beginning of his career, he has specialized in Oracle Technologies and is Oracle Certified Professional 12c and Oracle Certified Expert RAC\/GridInfra. Over time, Daniel has become increasingly interested in open source technologies, becoming \u201cTechnology Leader Open Infrastructure\u201d and PostgreSQL expert. \u00a0Based on community or EnterpriseDB tools, he develops and installs complex high available solutions with PostgreSQL. He is also a certified PostgreSQL Plus 9.0 Professional and a Postgres Advanced Server 9.4 Professional. He is a regular speaker at PostgreSQL conferences in Switzerland and Europe. Today Daniel is also supporting our customers on AWS services such as AWS RDS, database migrations into the cloud, EC2 and automated infrastructure management with AWS SSM (System Manager). He is a certified AWS Solutions Architect Professional. Prior to dbi services, Daniel was Management System Engineer at LC SYSTEMS-Engineering AG in Basel. Before that, he worked as Oracle Developper &\u00a0Project Manager at Delta Energy Solutions AG in Basel (today Powel AG). Daniel holds a diploma in Business Informatics (DHBW, Germany). His branch-related experience mainly covers the pharma industry, the financial sector, energy, lottery and telecommunications.","sameAs":["https:\/\/x.com\/westermanndanie"],"url":"https:\/\/www.dbi-services.com\/blog\/author\/daniel-westermann\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/11974","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/29"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=11974"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/11974\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=11974"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=11974"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=11974"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=11974"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}