\n Aggregate (cost=295.29..295.30 rows=1 width=8) (actual time=2.192..2.193 rows=1 loops=1)\n Output: sum(n)\n Buffers: shared hit=30\n -> Index Only Scan using demo1_n on public.demo1 (cost=0.29..270.29 rows=10000 width=4) (actual time=0.150..1.277 rows=10000 loops=1)\n Output: n\n Heap Fetches: 0\n Buffers: shared hit=30\n<\/code><\/pre>\nBasically, this reads all values of the column N and then aggregates them to the sum.
\nIf I remove the SUM() I have only the part that reads all values from N:<\/p>\n
\nexplain (analyze,verbose,costs,buffers) select n from demo1 ;\n QUERY PLAN\n-------------------------------------------------------------------------------------------------------------------------------------\n Index Only Scan using demo1_n on public.demo1 (cost=0.29..270.29 rows=10000 width=4) (actual time=0.150..1.284 rows=10000 loops=1)\n Output: n\n Heap Fetches: 0\n Buffers: shared hit=30\n Planning time: 0.440 ms\n Execution time: 1.972 ms\n<\/code><\/pre>\nOracle<\/h3>\n
This sounds logical. Now let’s run the same query, a simple ‘select n from demo1’ in Oracle:<\/p>\n
\nPLAN_TABLE_OUTPUT\n------------------------------------------------------------------------------------------------------------------------------------------------------\nSQL_ID ad4z7tpt0dkta, child number 0\n-------------------------------------\nselect \/*+ *\/ n from demo1\n--------------------------------------------------------------------------------------------------\n| Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| A-Rows | A-Time | Buffers |\n--------------------------------------------------------------------------------------------------\n| 0 | SELECT STATEMENT | | 1 | | 397 (100)| 10000 |00:00:00.01 | 1451 |\n| 1 | TABLE ACCESS FULL| DEMO1 | 1 | 10000 | 397 (0)| 10000 |00:00:00.01 | 1451 |\n--------------------------------------------------------------------------------------------------\nColumn Projection Information (identified by operation id):\n-----------------------------------------------------------\n 1 - \"N\"[NUMBER,22]\n<\/code><\/pre>\nHere the access path is different: a full table scan instead of an index only access (Index Fast Full Scan). It is not a cost decision. If we try to force an index access, with INDEX_FFS() or INDEX() hints, the query will still do a Full Table Scan. The reason is that and index only access is possible only if all columns and all rows are present in the index. But Oracle does not always index all rows. The Oracle index has no entry for the rows where all the indexed columns are nulls.<\/p>\n
Where n is not null<\/h3>\n
If I run the same query with the purpose of showing only non-null values, with a ‘where n is not null’ predicate, then an index only access is possible:<\/p>\n
\nPLAN_TABLE_OUTPUT\n------------------------------------------------------------------------------------------------------------------------------------------------------\nSQL_ID 2gbjpw5u0v9cw, child number 0\n-------------------------------------\nselect \/*+ *\/ n from demo1 where n is not null\n-------------------------------------------------------------------------------------------------------\n| Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| A-Rows | A-Time | Buffers |\n-------------------------------------------------------------------------------------------------------\n| 0 | SELECT STATEMENT | | 1 | | 7 (100)| 10000 |00:00:00.01 | 28 |\n| 1 | INDEX FAST FULL SCAN| DEMO1_N | 1 | 10000 | 7 (0)| 10000 |00:00:00.01 | 28 |\n-------------------------------------------------------------------------------------------------------\nPredicate Information (identified by operation id):\n---------------------------------------------------\n 1 - filter(\"N\" IS NOT NULL)\n<\/code><\/pre>\nConstraints<\/h3>\n
An alternative, if we know that we will never have null values here, is to give the information to the optimizer that there are no null values in the column N:
\nIn Oracle:<\/p>\n
alter table demo1 modify n not null;<\/code><\/pre>\nThis is the equivalent of the PostgreSQL<\/p>\n
alter table demo1 alter column n set not null;<\/code><\/pre>\nThen, in addition to ensuring the verification of the constraint, the constraint informs the optimizer that there is no null values and that all rows can be find in the index:<\/p>\n
\nPLAN_TABLE_OUTPUT\n------------------------------------------------------------------------------------------------------------------------------------------------------\nSQL_ID ad4z7tpt0dkta, child number 0\n-------------------------------------\nselect \/*+ *\/ n from demo1\n-------------------------------------------------------------------------------------------------------\n| Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| A-Rows | A-Time | Buffers |\n-------------------------------------------------------------------------------------------------------\n| 0 | SELECT STATEMENT | | 1 | | 7 (100)| 10000 |00:00:00.01 | 28 |\n| 1 | INDEX FAST FULL SCAN| DEMO1_N | 1 | 10000 | 7 (0)| 10000 |00:00:00.01 | 28 |\n-------------------------------------------------------------------------------------------------------\nColumn Projection Information (identified by operation id):\n-----------------------------------------------------------\n 1 - \"N\"[NUMBER,22]\n<\/code><\/pre>\nAdditional columns<\/h3>\n
Even if the column can have some null values, it is easy to have an index on null values in Oracle, just by adding a non-null column or expression. And if you don’t need this additional column, you can even add a constant, such as in the following index definition:<\/p>\n
\ncreate unique index demo1_n on demo1(n,0);\n<\/code><\/pre>\nThis works because all index entries have at least one non null value. But looking at the buffers you can see that this additional byte (0 is stored in 1 byte) has a little overhead (31 blocks read here instead of 28):<\/p>\n
\nPLAN_TABLE_OUTPUT\n------------------------------------------------------------------------------------------------------------------------------------------------------\nSQL_ID ad4z7tpt0dkta, child number 0\n-------------------------------------\nselect \/*+ *\/ n from demo1\n-------------------------------------------------------------------------------------------------------\n| Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| A-Rows | A-Time | Buffers |\n-------------------------------------------------------------------------------------------------------\n| 0 | SELECT STATEMENT | | 1 | | 8 (100)| 10000 |00:00:00.01 | 31 |\n| 1 | INDEX FAST FULL SCAN| DEMO1_N | 1 | 10000 | 8 (0)| 10000 |00:00:00.01 | 31 |\n-------------------------------------------------------------------------------------------------------\nColumn Projection Information (identified by operation id):\n-----------------------------------------------------------\n 1 - \"N\"[NUMBER,22]\n<\/code><\/pre>\nOracle Partial Indexes<\/h3>\n
In Oracle, all indexes that include a nullable column are partial indexes: not all rows are indexed, and an index access is possible only if the WHERE clause, or a constraint, guarantees that we don’t need the non-indexed rows. Combined with expression, it can be a way to implement partial indexes when the expression returns null for a specific condition. Oracle even provides computed columns (aka virtual columns) so that the expression does not have to be coded in the where clause of the query.<\/p>\n
As an example with expressions, the following index has entries only for the values lower than 10:<\/p>\n
create index demo_top10 on demo1(case when n<=10 then n end)<\/code><\/pre>\nHowever, to use it, we must mention the expression explicitly:<\/p>\n
\nPLAN_TABLE_OUTPUT\n------------------------------------------------------------------------------------------------------------------------------------------------------\nSQL_ID 863drbjwayrt7, child number 0\n-------------------------------------\nselect \/*+ *\/ (case when n<=10 then n end) from demo1 where (case when\nn<=10 then n end)<=5\n---------------------------------------------------------------------------------------------------------\n| Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| A-Rows | A-Time | Buffers |\n---------------------------------------------------------------------------------------------------------\n| 0 | SELECT STATEMENT | | 1 | | 1 (100)| 4 |00:00:00.01 | 2 |\n|* 1 | INDEX RANGE SCAN| DEMO1_N_TOP10 | 1 | 5 | 1 (0)| 4 |00:00:00.01 | 2 |\n---------------------------------------------------------------------------------------------------------\nPredicate Information (identified by operation id):\n---------------------------------------------------\n 1 - access("DEMO1"."SYS_NC00004$"<=5)\nColumn Projection Information (identified by operation id):\n-----------------------------------------------------------\n 1 - "DEMO1"."SYS_NC00004$"[NUMBER,22]\n<\/code><\/pre>\nWe can see that internally, a virtual column (“SYS_NC00004$”) has been created for the indexed expression, and is used for the predicate and the projection which uses the same expression. There is another possibility with the ‘partial index’ feature introduced in 12c<\/i> but it has not the flexibility of a predicate: it is based on partitioning where only some partitions can be indexed.<\/p>\nPostgres Partial Indexes<\/h3>\n
Postgres does not need those workarounds. An index indexes all rows, including null entries, and partial indexes can be defined with a where clause:<\/p>\n
create index demo_top10 on demo1(n) where n<=10<\/code><\/pre>\nNo need to change the query. As long as the result can come from the partial index, we can use the column without an expression on it:<\/p>\n
\nexplain (analyze,verbose,costs,buffers) select n from demo1 where n<=5 ;\n QUERY PLAN\n---------------------------------------------------------------------------------------------------------------------------------\n Index Only Scan using demo1_n_top10 on public.demo1 (cost=0.14..4.21 rows=4 width=4) (actual time=0.114..0.114 rows=5 loops=1)\n Output: n\n Index Cond: (demo1.n <= 5)\n Heap Fetches: 0\n Buffers: shared hit=2\n Planning time: 0.557 ms\n Execution time: 0.129 ms\n<\/code><\/pre>\nHere the smaller partial index (demo1_n_top10) has been chosen by the query planner.<\/p>\n
As you see I’ve not used exactly the same condition. The query planner understood that n<=5 (in the WHERE clause) is a subset of n<=10 (in the index definition). However, if the predicate is too different, it cannot use the index:<\/p>\n
\nfpa=# explain (analyze,verbose,costs,buffers) select n from demo1 where 2*n<=10;\n QUERY PLAN\n--------------------------------------------------------------------------------------------------------------------------------\n Index Only Scan using demo1_n on public.demo1 (cost=0.29..320.29 rows=3333 width=4) (actual time=0.020..1.086 rows=5 loops=1)\n Output: n\n Filter: ((2 * demo1.n) <= 10)\n Rows Removed by Filter: 9995\n Heap Fetches: 0\n Buffers: shared hit=30\n<\/code><\/pre>\nHere, instead of “Index Cond” we have a simple “Filter”. The Index Only Scan has read all the rows, and they were filtered afterward (“Rows Removed by Filter”).<\/p>\n
Index condition<\/h3>\n
With the VERBOSE option of EXPLAIN we see the condition used by the index access:<\/p>\n
Index Cond: (demo1.n <= 5)<\/code><\/pre>\n‘Index Cond.’ is not a simple filter removing rows after an operation, but it is the condition which is used for fast access to the index entries in the sorted index structure. We have the equivalent in Oracle with the ‘+predicate’ format of dbms_xplan:<\/p>\n
\nPredicate Information (identified by operation id):\n---------------------------------------------------\n 1 - access(\"N\"<=5)\n<\/code><\/pre>\nBefore going further on index access for WHERE clause predicate, the next post<\/a> will show the major characteristic of indexes (besides the fact that it stores a redundant subset of columns and rows): they are maintained sorted and may return the resulting rows in order.<\/p>\n","protected":false},"excerpt":{"rendered":"By Franck Pachot . In the previous post I said that an Index Only Access needs to find all rows in the index. Here is a case where, with similar data, Postgres can find all rows but Oracle needs additional considerations.<\/p>\n","protected":false},"author":27,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[59,83],"tags":[348,96,77],"type_dbi":[],"class_list":["post-10366","post","type-post","status-publish","format-standard","hentry","category-oracle","category-postgresql","tag-execution-plan","tag-oracle","tag-postgresql"],"acf":[],"yoast_head":"\n
Postgres vs. Oracle access paths III - Partial Index - dbi Blog<\/title>\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\/postgres-vs-oracle-access-paths-iii\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Postgres vs. Oracle access paths III - Partial Index\" \/>\n<meta property=\"og:description\" content=\"By Franck Pachot . In the previous post I said that an Index Only Access needs to find all rows in the index. Here is a case where, with similar data, Postgres can find all rows but Oracle needs additional considerations.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/postgres-vs-oracle-access-paths-iii\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2017-08-03T13:58:03+00:00\" \/>\n<meta name=\"author\" content=\"Oracle Team\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Oracle Team\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"7 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\\\/postgres-vs-oracle-access-paths-iii\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/postgres-vs-oracle-access-paths-iii\\\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"Postgres vs. Oracle access paths III – Partial Index\",\"datePublished\":\"2017-08-03T13:58:03+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/postgres-vs-oracle-access-paths-iii\\\/\"},\"wordCount\":830,\"commentCount\":0,\"keywords\":[\"Execution plan\",\"Oracle\",\"PostgreSQL\"],\"articleSection\":[\"Oracle\",\"PostgreSQL\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/postgres-vs-oracle-access-paths-iii\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/postgres-vs-oracle-access-paths-iii\\\/\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/postgres-vs-oracle-access-paths-iii\\\/\",\"name\":\"Postgres vs. Oracle access paths III - Partial Index - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\"},\"datePublished\":\"2017-08-03T13:58:03+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/66ab87129f2d357f09971bc7936a77ee\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/postgres-vs-oracle-access-paths-iii\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/postgres-vs-oracle-access-paths-iii\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/postgres-vs-oracle-access-paths-iii\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Postgres vs. Oracle access paths III – Partial Index\"}]},{\"@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\\\/66ab87129f2d357f09971bc7936a77ee\",\"name\":\"Oracle Team\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"caption\":\"Oracle Team\"},\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/author\\\/oracle-team\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Postgres vs. Oracle access paths III - Partial Index - dbi Blog","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\/postgres-vs-oracle-access-paths-iii\/","og_locale":"en_US","og_type":"article","og_title":"Postgres vs. Oracle access paths III - Partial Index","og_description":"By Franck Pachot . In the previous post I said that an Index Only Access needs to find all rows in the index. Here is a case where, with similar data, Postgres can find all rows but Oracle needs additional considerations.","og_url":"https:\/\/www.dbi-services.com\/blog\/postgres-vs-oracle-access-paths-iii\/","og_site_name":"dbi Blog","article_published_time":"2017-08-03T13:58:03+00:00","author":"Oracle Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Oracle Team","Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/postgres-vs-oracle-access-paths-iii\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/postgres-vs-oracle-access-paths-iii\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"Postgres vs. Oracle access paths III – Partial Index","datePublished":"2017-08-03T13:58:03+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/postgres-vs-oracle-access-paths-iii\/"},"wordCount":830,"commentCount":0,"keywords":["Execution plan","Oracle","PostgreSQL"],"articleSection":["Oracle","PostgreSQL"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/postgres-vs-oracle-access-paths-iii\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/postgres-vs-oracle-access-paths-iii\/","url":"https:\/\/www.dbi-services.com\/blog\/postgres-vs-oracle-access-paths-iii\/","name":"Postgres vs. Oracle access paths III - Partial Index - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2017-08-03T13:58:03+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/postgres-vs-oracle-access-paths-iii\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/postgres-vs-oracle-access-paths-iii\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/postgres-vs-oracle-access-paths-iii\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Postgres vs. Oracle access paths III – Partial Index"}]},{"@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\/66ab87129f2d357f09971bc7936a77ee","name":"Oracle Team","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","caption":"Oracle Team"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/oracle-team\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/10366","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\/27"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=10366"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/10366\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=10366"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=10366"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=10366"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=10366"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}