{"id":73303,"date":"2012-07-05T11:52:28","date_gmt":"2012-07-05T11:52:28","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/uncategorized\/dynamic-sampling-iii-real-life-data-part-ii\/"},"modified":"2021-07-14T13:07:55","modified_gmt":"2021-07-14T13:07:55","slug":"dynamic-sampling-iii-real-life-data-part-ii","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/databases\/oracle-databases\/dynamic-sampling-iii-real-life-data-part-ii\/","title":{"rendered":"Dynamic Sampling (III) – Real-Life Data – Part II"},"content":{"rendered":"

In the previous installment<\/a> of this series we saw that Dynamic Sampling wasn’t of great help when dealing with certain types of data patterns. We tried to add a suitable index to improve the Dynamic Sampling results, but no luck so far.<\/p>\n

The solution in this case is that with statistics in place the index only gets used when adding the DYNAMIC_SAMPLING_EST_CDN<\/strong> hint (see the previous parts<\/a> of the series for an explanation of that hint). I’m not sure why this is as in my understanding it is only used to improve<\/strong> the selectivity estimate and not to overwrite<\/strong> existing cardinality\/blocks statistics, but that’s the way the code at present works.<\/p>\n

Re-running the experiment now looks like this:<\/p>\n

set echo on\r\n\r\nalter session set tracefile_identifier = 'dyn_samp';\r\n\r\nalter session set optimizer_dynamic_sampling = 4;\r\n\r\nalter session set events '10053 trace name context forever, level 1';\r\n\r\nexplain plan for\r\nselect  \/*+ DYNAMIC_SAMPLING_EST_CDN(pcl)<\/strong><\/span> *\/\r\n        *\r\nfrom\r\n        parcels pcl\r\nwhere\r\n        pcl.pickup_date >= sysdate - 1\r\nand     pcl.delivery_status = 'In-transit'\r\n;\r\n\r\nselect * from table(dbms_xplan.display);<\/pre>\n
And the results:<\/p>\n
-------------------------------------------------------------------------------------------\r\n| Id\u00a0 | Operation\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 | Name\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 | Rows\u00a0 | Bytes | Cost (%CPU)| Time\u00a0\u00a0\u00a0\u00a0 |\r\n-------------------------------------------------------------------------------------------\r\n|\u00a0\u00a0 0 | SELECT STATEMENT\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\u00a0 1000 |\u00a0\u00a0 180K|\u00a0\u00a0\u00a0 42\u00a0\u00a0 (0)| 00:00:01 |\r\n|\u00a0\u00a0 1 |\u00a0 TABLE ACCESS BY INDEX ROWID| PARCELS\u00a0\u00a0\u00a0\u00a0 |\u00a0 1000<\/strong><\/span> |\u00a0\u00a0 180K|\u00a0\u00a0\u00a0 42\u00a0\u00a0 (0)| 00:00:01 |\r\n|*\u00a0 2 |\u00a0\u00a0 INDEX RANGE SCAN\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 | PARCELS_IDX |\u00a0 1282 |\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\u00a0\u00a0\u00a0\u00a0 8\u00a0\u00a0 (0)| 00:00:01 |\r\n-------------------------------------------------------------------------------------------\r\n\r\nPredicate Information (identified by operation id):\r\n---------------------------------------------------\r\n\r\n   2 - access(\"PCL\".\"DELIVERY_STATUS\"='In-transit' AND \"PCL\".\"PICKUP_DATE\">=SYSDATE@!-1 AND \"PCL\".\"PICKUP_DATE\" IS NOT NULL)\r\n\r\nNote\r\n-----\r\n   - dynamic sampling used for this statement (level=4)<\/pre>\n
And the trace file shows:<\/p>\n
** Dynamic sampling initial checks returning TRUE (level = 4).\r\n** Dynamic sampling updated index stats<\/strong><\/span>.: PARCELS_IDX, blocks=4065\r\n** Dynamic sampling index access candidate : PARCELS_IDX\r\n** Dynamic sampling updated table stats.<\/strong><\/span>: blocks=26518\r\n\r\n*** 2012-05-29 19:00:40.282\r\n** Generated dynamic sampling query:\r\nquery text :\r\nSELECT \/* OPT_DYN_SAMP *\/ \/*+ ALL_ROWS IGNORE_WHERE_CLAUSE NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false') NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE *\/ NVL(SUM(C1),0), NVL(SUM(C2),0) FROM (SELECT \/*+ IGNORE_WHERE_CLAUSE NO_PARALLEL(\"PCL\") FULL(\"PCL\") NO_PARALLEL_INDEX(\"PCL\") *\/ 1 AS C1, CASE WHEN \"PCL\".\"DELIVERY_STATUS\"='In-transit' AND \"PCL\".\"PICKUP_DATE\">=SYSDATE@!-1 THEN 1 ELSE 0 END AS C2 FROM \"PARCELS\" SAMPLE BLOCK (0.116902 , 1) SEED (1) \"PCL\") SAMPLESUB\r\n\r\n*** 2012-05-29 19:00:40.297\r\n** Executed dynamic sampling query:\r\nlevel : 4\r\nsample pct. : 0.116902\r\nactual sample size : 912\r\nfiltered sample card. : 0\r\norig. card. : 1000000\r\nblock cnt. table stat. : 26518\r\nblock cnt. for sampling: 26518\r\nmax. sample block cnt. : 32\r\nsample block cnt. : 31\r\nmin. sel. est. : 0.00000102\r\n** Using recursive dynamic sampling card. est. : 780142.451613<\/strong><\/span>\r\n\r\n*** 2012-05-29 19:00:40.297\r\n** Generated dynamic sampling query:\r\nquery text :\r\nSELECT \/* OPT_DYN_SAMP *\/ \/*+ ALL_ROWS opt_param('parallel_execution_enabled', 'false') NO_PARALLEL(SAMPLESUB) NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE *\/ NVL(SUM(C1),0), NVL(SUM(C2),0), NVL(SUM(C3),0) FROM (SELECT \/*+ NO_PARALLEL(\"PCL\") INDEX(\"PCL\" PARCELS_IDX) NO_PARALLEL_INDEX(\"PCL\") *\/ 1 AS C1, 1 AS C2, 1 AS C3\u00a0 FROM \"PARCELS\" \"PCL\" WHERE \"PCL\".\"DELIVERY_STATUS\"='In-transit' AND \"PCL\".\"PICKUP_DATE\">=SYSDATE@!-1 AND ROWNUM <= 2500) SAMPLESUB\r\n\r\n*** 2012-05-29 19:00:40.297\r\n** Executed dynamic sampling query:\r\nlevel : 4\r\nsample pct. : 100.000000\r\nactual sample size : 780142\r\nfiltered sample card. : 1000<\/strong><\/span>\r\nfiltered sample card. (index PARCELS_IDX): 1000<\/strong><\/span>\r\norig. card. : 780142\r\nblock cnt. table stat. : 26518\r\nblock cnt. for sampling: 26518\r\nmax. sample block cnt. : 4294967295\r\nsample block cnt. : 26518\r\nmin. sel. est. : 0.00000102\r\nindex PARCELS_IDX selectivity est.: 0.00128182\r\n** Using dynamic sampling card. : 780142<\/strong> ** Using single table dynamic sel. est. : 0.00128182<\/strong><\/span>\r\nTable: PARCELS\u00a0 Alias: PCL\r\nCard: Original: 780142.451613\u00a0 Rounded: 1000\u00a0 Computed: 1000.00\u00a0 Non Adjusted: 1000.00<\/pre>\n
That looks very promising – with a very small overhead<\/strong> we get a spot on<\/strong> cardinality estimate. Note that by small overhead I mean the sampling overhead, of course there is the additional overhead of maintaining the index if it was added only for that specific purpose.<\/p>\n
If you check the optimizer trace file carefully, you’ll notice two recursive queries<\/strong> issued by the Dynamic Sampling code. The first one corresponds to those we’ve already seen, but the second one is different: It explicitly uses the index PARCELS_IDX<\/strong>; doesn’t use the SAMPLE<\/strong> clause but restricts the result set to the first 2,500 rows<\/strong>.<\/p>\n
The idea seems to be that if Oracle finds a suitable index<\/strong> and decides to use it (more on that in a moment) it can very cheaply check for a very precise<\/strong> selectivity \/ cardinality estimate in case of rare values (which in this case means less than 2,500 occurrences<\/strong>) based on the index.<\/p>\n
What happens if the index query identifies 2,500 rows (or more)? In that case Oracle doesn’t know exactly how many rows are identified and it uses the greater cardinality<\/strong> of the two queries to arrive at the cardinality estimate. This means that depending on the data pattern and the results of the two queries you might end up with a pretty incorrect<\/strong> estimate, but it might at least be better than the result of the single query used by default.<\/p>\n
\n
Note: If you happen to use partitioned tables<\/strong> there are a number of nasty bugs related to Dynamic Sampling in versions prior to 11.2.0.2 \/ 11.2.0.3<\/strong> respectively. In particular the cardinality estimate based on the additional index-based query can be completely misleading<\/strong>, for more information see this blog post<\/a>.<\/p>\n<\/blockquote>\n
Unfortunately the code is at present pretty picky<\/strong> when deciding whether to use indexes<\/strong> or not.<\/p>\n
The first point is that for multi-column indexes<\/strong> to be used all predicates need to be index access<\/strong> predicates, which means the index won’t be used if at least one of the predicates can only be applied by filtering<\/strong> the index.<\/p>\n
For example, if the above index was created using the two columns in a different order (PICKUP_DATE, DELIVERY_STATUS), then it won’t be used since DELIVERY_STATUS cannot be used as an index access predicate due to the range comparison on PICKUP_DATE (this is implied by the different order<\/strong> of the index entries).<\/p>\n
I can understand this decision to a certain extent as otherwise it becomes unpredictable<\/strong> how many index blocks have to effectively be read to scan for 2,500 rows<\/strong> in the index.<\/p>\n
This also means that certain kinds of complex predicates<\/strong>, like for example:<\/p>\n
pickup_date >= sysdate - 1 and some_other_date >= sysdate - 5 and delivery_status = 'In-transit'<\/pre>\n
cannot<\/strong> be covered by Dynamic Sampling using indexes, since it is not possible to use all three predicates as access predicates no matter<\/strong> how the index is defined.<\/p>\n
What I can’t understand is the fact that adding another index that starts with<\/strong> one of the columns used as predicates disables<\/strong> the usage of the indexes completely<\/strong>.<\/p>\n
For example, if I add this index:<\/p>\n
create index parcels_idx2 on parcels (delivery_status);<\/pre>\n
this is the result for the previous, unchanged test case I get:<\/p>\n
-------------------------------------------------------------------------------------------\r\n| Id\u00a0 | Operation\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 | Name\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 | Rows\u00a0 | Bytes | Cost (%CPU)| Time\u00a0\u00a0\u00a0\u00a0 |\r\n-------------------------------------------------------------------------------------------\r\n|\u00a0\u00a0 0 | SELECT STATEMENT\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\u00a0\u00a0\u00a0\u00a0 1 |\u00a0\u00a0 193 |\u00a0\u00a0\u00a0\u00a0 4\u00a0\u00a0 (0)| 00:00:01 |\r\n|\u00a0\u00a0 1 |\u00a0 TABLE ACCESS BY INDEX ROWID| PARCELS\u00a0\u00a0\u00a0\u00a0 |\u00a0\u00a0\u00a0\u00a0 1<\/strong><\/span> |\u00a0\u00a0 193 |\u00a0\u00a0\u00a0\u00a0 4\u00a0\u00a0 (0)| 00:00:01 |\r\n|*\u00a0 2 |\u00a0\u00a0 INDEX RANGE SCAN\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 | PARCELS_IDX |\u00a0\u00a0\u00a0\u00a0 1 |\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\u00a0\u00a0\u00a0\u00a0 3\u00a0\u00a0 (0)| 00:00:01 |\r\n-------------------------------------------------------------------------------------------\r\n\r\nPredicate Information (identified by operation id):\r\n---------------------------------------------------\r\n\r\n   2 - access(\"PCL\".\"DELIVERY_STATUS\"='In-transit' AND \"PCL\".\"PICKUP_DATE\">=SYSDATE@!-1 AND \"PCL\".\"PICKUP_DATE\" IS NOT NULL)\r\n\r\nNote\r\n-----\r\n   - dynamic sampling used for this statement (level=4)<\/pre>\n
So we are back to square one. And this is what the optimizer trace file tells us:<\/p>\n
** Dynamic sampling initial checks returning TRUE (level = 4).\r\n** Dynamic sampling updated index stats<\/strong><\/span>.: PARCELS_IDX, blocks=4066\r\n** Dynamic sampling updated index stats<\/strong><\/span>.: PARCELS_IDX2, blocks=2934\r\n** Dynamic sampling updated table stats<\/strong><\/span>.: blocks=27984\r\n\r\n*** 2012-05-29 19:20:54.473\r\n** Generated dynamic sampling query:\r\nquery text :\r\nSELECT \/* OPT_DYN_SAMP *\/ \/*+ ALL_ROWS IGNORE_WHERE_CLAUSE NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false') NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE *\/ NVL(SUM(C1),0), NVL(SUM(C2),0), NVL(SUM(C3),0), NVL(SUM(C4),0) FROM (SELECT \/*+ IGNORE_WHERE_CLAUSE NO_PARALLEL(\"PCL\") FULL(\"PCL\") NO_PARALLEL_INDEX(\"PCL\") *\/ 1 AS C1, CASE WHEN \"PCL\".\"DELIVERY_STATUS\"='In-transit' AND \"PCL\".\"PICKUP_DATE\">=SYSDATE@!-1 THEN 1 ELSE 0 END AS C2, CASE WHEN \"PCL\".\"DELIVERY_STATUS\"='In-transit' THEN 1 ELSE 0 END AS C3, CASE WHEN \"PCL\".\"PICKUP_DATE\">=SYSDATE@!-1 AND \"PCL\".\"DELIVERY_STATUS\"='In-transit' THEN 1 ELSE 0 END AS C4 FROM \"PARCELS\" SAMPLE BLOCK (0.110778 , 1) SEED (1) \"PCL\") SAMPLESUB\r\n\r\n*** 2012-05-29 19:20:54.488\r\n** Executed dynamic sampling query:\r\nlevel : 4\r\nsample pct. : 0.110778\r\nactual sample size : 1260<\/strong><\/span>\r\nfiltered sample card. : 0<\/strong><\/span>\r\nfiltered sample card. (index PARCELS_IDX2): 0<\/strong><\/span>\r\nfiltered sample card. (index PARCELS_IDX): 0<\/strong><\/span>\r\norig. card. : 1000000\r\nblock cnt. table stat. : 27984\r\nblock cnt. for sampling: 27984\r\nmax. sample block cnt. : 32\r\nsample block cnt. : 31<\/strong><\/span>\r\nmin. sel. est. : 0.00000064\r\n** Using dynamic sampling card. : 1137414<\/strong><\/span>\r\n\r\nTable: PARCELS\u00a0 Alias: PCL\r\nCard: Original: 1137414.193548\u00a0 Rounded: 1\u00a0 Computed: 0.73\u00a0 Non Adjusted: 0.73<\/pre>\n
So both indexes were recognized<\/strong>, but none of them were used to run the index-based query. I believe this could be classified as a bug<\/strong>, but all versions up to the latest one available at the time of writing this (11.2.0.3) show this behaviour.<\/p>\n
\n
Note: You’ll notice that using the DYNAMIC_SAMPLING_EST_CDN<\/strong> hint seems to implicitly override the sanity checks – the results of the Dynamic Sampling get used even with questionable results. This is something to keep in mind when using the approach outlined here.<\/p>\n<\/blockquote>\n
Beyond Dynamic Sampling And Indexes<\/h2>\n
If you happen to have such cases that you can’t cover<\/strong> with either Dynamic Sampling, potentially supported by indexes, nor Extended Statistics on Column Groups, then you might be able to get improved cardinality estimates by using suitable Virtual Columns or Extended Statistics expressions<\/strong>.<\/p>\n
This is, however, only applicable in cases where you can change<\/strong> the query the application submits, and where you know the expressions upfront<\/strong>.<\/p>\n
For our example here, assuming the index option is not feasible for whatever reason, you could try to add the following Virtual Column or Extended Statistics expression (only from 11g on, pre-11g would need a corresponding Function-Based Index<\/strong>):<\/p>\n
alter table parcels add (rare_vals as (cast(case when pickup_date >= sysdate - 1 and delivery_status = 'In-transit' then 'Y' else null end) as varchar2(1));<\/pre>\n
only to find out that you get an error<\/strong> “only pure functions can be specified in a virtual column expression”, due to the SYSDATE expression.<\/p>\n
Assuming a suitable expression, just as an example here (adjust the literal expression as necessary):<\/p>\n
alter table parcels add (rare_vals as (cast(case when pickup_date >= to_date('30.05.2012 09:13:16', 'DD.MM.YYYY HH24:MI:SS') and delivery_status = 'In-transit' then 'Y' else null end) as varchar2(1));<\/pre>\n
you can add such a virtual column and after gathering statistics on that column:<\/p>\n
exec dbms_stats.gather_table_stats(null, 'parcels', method_opt => 'for columns size 1 rare_vals')<\/pre>\n
\n
Note: It’s very important to remember that Extended Statistics, Virtual Columns (or the Virtual Columns added implicitly via Function-Based Indexes) need to have statistics gathered<\/strong> for, otherwise the optimizer can’t leverage the added value of such expressions. Although default METHOD_OPT options like “FOR ALL COLUMNS SIZE AUTO” will include such additional columns<\/strong> the next time statistics are gathered, it is important to explicitly<\/strong> gather statistics after you’ve just added<\/strong> such columns if you want to take full advantage of them<\/p>\n<\/blockquote>\n
You could run a query like the following, without<\/strong> the need for Dynamic Sampling, indexes or even histograms:<\/p>\n
explain plan for\r\nselect\r\n        *\r\nfrom\r\n        parcels pcl\r\nwhere\r\n        rare_vals = 'Y'\r\n;\r\n\r\nselect * from table(dbms_xplan.display);\r\n\r\n-----------------------------------------------------------------------------\r\n| Id\u00a0 | Operation\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 | Name\u00a0\u00a0\u00a0 | Rows\u00a0 | Bytes | Cost (%CPU)| Time\u00a0\u00a0\u00a0\u00a0 |\r\n-----------------------------------------------------------------------------\r\n|\u00a0\u00a0 0 | SELECT STATEMENT\u00a0 |\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\u00a0 1000 |\u00a0\u00a0 189K|\u00a0 7743\u00a0\u00a0 (3)| 00:01:33 |\r\n|*\u00a0 1 |\u00a0 TABLE ACCESS FULL| PARCELS |\u00a0 1000<\/strong><\/span> |\u00a0\u00a0 189K|\u00a0 7743\u00a0\u00a0 (3)| 00:01:33 |\r\n-----------------------------------------------------------------------------\r\n\r\nPredicate Information (identified by operation id):\r\n---------------------------------------------------\r\n\r\n   1 - filter(\"RARE_VALS\"='Y')<\/pre>\n
So the cardinality estimate is spot on, but you need to know the expressions upfront, they need to be static<\/strong> and the expression needs to be supported<\/strong> by the Virtual Column code. Of course this approach could be further refined to serve more complex expressions, but then again histograms might be required to handle the virtual column data statistics properly.<\/p>\n
Summary<\/h2>\n
Dynamic Sampling can be very useful, but if you’re looking for rare values<\/strong>, or if the data you’re looking for is not uniformly distributed<\/strong> across the table but clustered together<\/strong>, the default Dynamic Sampling might fail to produce helpful results.<\/p>\n
Sometimes you might be able to get Dynamic Sampling working by adding a suitable index<\/strong>, but you need to check carefully if the Dynamic Sampling code decides to actually use the index<\/strong> or not, and if statistics exist, you need to explicitly specify the DYNAMIC_SAMPLING_EST_CDN<\/strong> hint for the table in question, which is a pity, because it makes generic implementations more complex.<\/p>\n
In other cases where you can influence the query issued you might able to overcome such issues by using corresponding Virtual Column expressions, if these are static<\/strong> in nature and supported<\/strong> by the Virtual Column code.<\/p>\n
The purpose<\/strong> of the whole exercise is to arrive at more reasonable cardinality estimates<\/strong> – based on the knowledge that incorrect<\/strong> cardinality estimates are very often the root cause<\/strong> of inefficient execution plans (If you want to learn more why this is so important, you could watch my Webinar recording<\/a> available here on Cost-Based Optimizer Basics).<\/p>\n
Go to Dynamic Sampling (III) – Real-Life Data – Part I<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
In the previous installment of this series we saw that Dynamic Sampling wasn’t of great help when dealing with certain types of data patterns. We tried to add a suitable index to improve the Dynamic Sampling results, but no luck so far. The solution in this case is that with statistics in place the index only gets used when adding…<\/p>\n","protected":false},"author":316197,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[143533],"tags":[],"coauthors":[],"class_list":["post-73303","post","type-post","status-publish","format-standard","hentry","category-oracle-databases"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/73303","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/316197"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=73303"}],"version-history":[{"count":1,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/73303\/revisions"}],"predecessor-version":[{"id":91755,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/73303\/revisions\/91755"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=73303"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=73303"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=73303"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=73303"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}