{"id":1029,"date":"2025-05-27T09:00:00","date_gmt":"2025-05-27T14:00:00","guid":{"rendered":"https:\/\/www.sqltabletalk.com\/?p=1029"},"modified":"2025-05-25T13:25:57","modified_gmt":"2025-05-25T18:25:57","slug":"filtered-indexes-in-sql-server","status":"publish","type":"post","link":"https:\/\/www.sqltabletalk.com\/?p=1029","title":{"rendered":"Filtered Indexes in SQL Server: Targeted Performance in High-Volume Tables"},"content":{"rendered":"

Introduction<\/h2>\n

When a table holds millions of rows yet most queries touch only a small, well-defined subset, a traditional non-clustered index feels like using a searchlight to find something sitting under a desk lamp: the index still stores an entry for every row even though the workload rarely needs most of them. SQL Server\u2019s answer is the filtered index<\/strong>\u2014introduced in SQL Server 2008 and still under-used today\u2014allowing you to index just the rows that match a predicate you supply in a WHERE<\/code> clause.<\/p>\n

What a filtered index actually is<\/h3>\n

Internally a filtered index is simply a regular non-clustered index whose leaf level contains only the rows that satisfy the filter predicate. That predicate can reference any deterministic, non-computed column in the table and can combine multiple columns with standard Boolean operators. SQL Server also maintains a set of statistics scoped to that filtered subset, so the optimiser can estimate cardinality far more accurately than it can with a full-table index plus residual predicate. The result is leaner storage, faster seeks, and often a simpler plan shape because the engine can avoid scanning or re-checking unwanted rows.<\/p>\n

Why it helps<\/h3>\n

Smaller footprint means less I\/O during index maintenance and fewer pages in memory while the query runs. That has a cascading effect: buffer-cache pressure falls, latch contention on the index drops, and log writes during updates shrink because fewer rows participate. The filtered statistics improve plan quality, especially on highly skewed data where a general histogram is too coarse. Finally, filtered indexes lend themselves to targeted covering strategies: you can include only the columns needed by the subset of queries that actually use the index instead of bloating a wider structure that must serve every access pattern.<\/p>\n

Designing the predicate<\/h3>\n

A filtered index pays off only when its predicate aligns exactly with the predicates in your queries. For instance, imagine a Sales.Orders<\/code> table in which closed orders outnumber active ones fifty to one but dashboards and operational reports read only the active set. The ideal filter here is WHERE Status = 'Active'<\/code>. If you sometimes parameterise Status<\/code> and at other times hard-code it, parameter sniffing can produce plans that do not use the filtered index, so consistency in query patterns matters. The predicate must also be stable enough that data churn inside the filtered set stays low; otherwise the maintenance savings disappear.<\/p>\n

Creating a filtered index: a worked example<\/h3>\n
\/* Sample workload: open orders queried far more often than closed ones *\/\nUSE AdventureWorks2022;\nGO\n\n\/* Baseline query without the filtered index *\/\nSET STATISTICS IO ON;\nGO\n\nSELECT SalesOrderID, OrderDate, CustomerID\nFROM Sales.SalesOrderHeader\nWHERE OrderStatus = 1;          -- 1 = Open\nGO\n\n\/* Build the filtered index *\/\nCREATE NONCLUSTERED INDEX IX_SalesOrderHeader_OpenOrders\n    ON Sales.SalesOrderHeader (OrderStatus)          -- key column\n    INCLUDE (SalesOrderID, OrderDate, CustomerID)    -- covering columns\n    WHERE OrderStatus = 1;                           -- filter predicate\nGO\n\n\/* Rerun the same query to observe the difference *\/\nSELECT SalesOrderID, OrderDate, CustomerID\nFROM Sales.SalesOrderHeader\nWHERE OrderStatus = 1;\nGO\nSET STATISTICS IO OFF;<\/code><\/pre>\n
After the index is created the execution plan should switch from a full non-clustered index scan\u2014or even a clustered scan if no suitable index existed\u2014to a seek that touches only the handful of pages holding open orders. STATISTICS IO<\/code> now reports dramatically fewer logical reads. Storage drops as well; on a table where ninety-five percent of orders are closed, the filtered index might weigh in at one-twentieth the size of an equivalent unfiltered one.<\/p>\n
Updating data and statistics<\/h3>\n
Because the index tracks only rows that satisfy its predicate, inserts and deletes outside the filter have no effect on it. Updates that move a row in or out of the filtered set, however, translate into delete\/insert pairs under the hood, so bursty transitions can inflate fragmentation. Standard index-maintenance commands (ALTER INDEX \u2026 REORGANIZE<\/code> or \u2026 REBUILD<\/code>) work just as they do for any non-clustered index. Statistics update automatically unless you have disabled auto-stats; if you manage stats manually remember that UPDATE STATISTICS<\/code> without the WITH FULLSCAN<\/code> hint samples only the filtered subset.<\/p>\n
Limitations and edge cases (explained more plainly)<\/h3>\n
A few hard rules and gotchas keep filtered indexes from being a silver-bullet solution:<\/p>\n
    \n
  • They must be non-clustered.<\/strong> You can\u2019t turn your clustered index into a filtered one; the feature only works on secondary (non-clustered) indexes.<\/li>\n
  • Key columns can\u2019t use LOB types.<\/strong> If a column is VARCHAR(MAX)<\/code>, NVARCHAR(MAX)<\/code>, VARBINARY(MAX)<\/code>, XML<\/code>, or another large-object type, it cannot sit in the key of the filtered index. You may still be able to put that column in the INCLUDE<\/code> list, because includes don\u2019t participate in ordering.<\/li>\n
  • No filtered index on a view.<\/strong> Indexed views ignore filter predicates entirely, so the optimiser won\u2019t create or use a filtered index there.<\/li>\n
  • Not eligible for foreign-key targets.<\/strong> Another table can\u2019t point a foreign key at a filtered index. If you need referential integrity, the primary key (or some other unfiltered unique index) has to handle it.<\/li>\n
  • Ignored by partition switching and indexed-view maintenance.<\/strong> When you switch partitions in or out, or when SQL Server updates an indexed view, it will skip any filtered indexes you created on the underlying table.<\/li>\n
  • Care needed with OR<\/code> logic.<\/strong> A query that says WHERE Status = 'Open' OR Status = 'Pending'<\/code> will not use the filtered index that covers only Status = 'Open'<\/code>, because the predicate no longer matches exactly. Ranges (<<\/code>, ><\/code>, BETWEEN<\/code>) are fine as long as the range fits inside the filter.<\/li>\n
  • Parameter-sensitive plans can still bite you.<\/strong> If one stored procedure sometimes runs for Status = 1<\/code> and sometimes for Status = 5<\/code>, the first execution decides whether the filtered index is used. To keep performance predictable you may need separate procedures, OPTION (RECOMPILE)<\/code>, or OPTIMIZE FOR<\/code> hints so each run gets its own plan.<\/li>\n<\/ul>\n
    Keep these constraints in mind while designing the index and writing queries, and you\u2019ll avoid most surprises.<\/p>\n
    Conclusion<\/h3>\n
    Filtered indexes provide a precise, low-overhead path to accelerating workloads that focus on narrow slices of large tables. By storing only the necessary rows and building statistics on exactly the data you care about, they combine lower maintenance cost with better plan quality. The key to unlocking their value is matching the filter to a stable, highly selective predicate in your production queries and ensuring that the code paths calling those queries remain consistent. Done well, the payoff is immediate: lighter I\/O, leaner memory usage, and faster response times\u2014without redesigning the table or rewriting existing indexes.<\/p>\n","protected":false},"excerpt":{"rendered":"
    When a table holds millions of rows yet most queries touch only a small, well-defined subset, a traditional non-clustered index feels like using a searchlight to find something sitting under a desk lamp: the index still stores an entry for every row even though the workload rarely needs most of them. SQL Server\u2019s answer is the filtered index\u2014introduced in SQL Server 2008 and still under-used today\u2014allowing you to index just the rows that match a predicate you supply in a WHERE clause.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[104,324,5,91,44],"tags":[539,535,542,541,537,538,540,43,131,45],"class_list":["post-1029","post","type-post","status-publish","format-standard","hentry","category-indexing","category-locking","category-performance","category-query-optimization","category-statistics","tag-database-tuning","tag-filtered-index","tag-high-volume-tables","tag-index-maintenance","tag-index-optimization","tag-non-clustered-index","tag-predicate-filtering","tag-query-performance","tag-sql-server","tag-statistics"],"yoast_head":"\nFiltered Indexes in SQL Server: Targeted Performance in High-Volume Tables - SQL Table Talk<\/title>\n<meta name=\"description\" content=\"When a table holds millions of rows yet most queries touch only a small, well-defined subset, a traditional non-clustered index feels like using a searchlight to find something sitting under a desk lamp: the index still stores an entry for every row even though the workload rarely needs most of them. SQL Server\u2019s answer is the filtered index\u2014introduced in SQL Server 2008 and still under-used today\u2014allowing you to index just the rows that match a predicate you supply in a WHERE clause.\" \/>\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.sqltabletalk.com\/?p=1029\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Filtered Indexes in SQL Server: Targeted Performance in High-Volume Tables - SQL Table Talk\" \/>\n<meta property=\"og:description\" content=\"When a table holds millions of rows yet most queries touch only a small, well-defined subset, a traditional non-clustered index feels like using a searchlight to find something sitting under a desk lamp: the index still stores an entry for every row even though the workload rarely needs most of them. SQL Server\u2019s answer is the filtered index\u2014introduced in SQL Server 2008 and still under-used today\u2014allowing you to index just the rows that match a predicate you supply in a WHERE clause.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.sqltabletalk.com\/?p=1029\" \/>\n<meta property=\"og:site_name\" content=\"SQL Table Talk\" \/>\n<meta property=\"article:published_time\" content=\"2025-05-27T14:00:00+00:00\" \/>\n<meta name=\"author\" content=\"Stephen Planck\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Stephen Planck\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"5 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.sqltabletalk.com\/?p=1029#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.sqltabletalk.com\/?p=1029\"},\"author\":{\"name\":\"Stephen Planck\",\"@id\":\"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/1947e42a9438bccd91691d8b791888e0\"},\"headline\":\"Filtered Indexes in SQL Server: Targeted Performance in High-Volume Tables\",\"datePublished\":\"2025-05-27T14:00:00+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.sqltabletalk.com\/?p=1029\"},\"wordCount\":944,\"commentCount\":2,\"publisher\":{\"@id\":\"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/1947e42a9438bccd91691d8b791888e0\"},\"keywords\":[\"database tuning\",\"filtered index\",\"high-volume tables\",\"index maintenance\",\"index optimization\",\"non-clustered index\",\"predicate filtering\",\"query performance\",\"SQL Server\",\"statistics\"],\"articleSection\":[\"Indexing\",\"Locking\",\"Performance\",\"Query Optimization\",\"Statistics\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.sqltabletalk.com\/?p=1029#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.sqltabletalk.com\/?p=1029\",\"url\":\"https:\/\/www.sqltabletalk.com\/?p=1029\",\"name\":\"Filtered Indexes in SQL Server: Targeted Performance in High-Volume Tables - SQL Table Talk\",\"isPartOf\":{\"@id\":\"https:\/\/www.sqltabletalk.com\/#website\"},\"datePublished\":\"2025-05-27T14:00:00+00:00\",\"description\":\"When a table holds millions of rows yet most queries touch only a small, well-defined subset, a traditional non-clustered index feels like using a searchlight to find something sitting under a desk lamp: the index still stores an entry for every row even though the workload rarely needs most of them. SQL Server\u2019s answer is the filtered index\u2014introduced in SQL Server 2008 and still under-used today\u2014allowing you to index just the rows that match a predicate you supply in a WHERE clause.\",\"breadcrumb\":{\"@id\":\"https:\/\/www.sqltabletalk.com\/?p=1029#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.sqltabletalk.com\/?p=1029\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.sqltabletalk.com\/?p=1029#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.sqltabletalk.com\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Filtered Indexes in SQL Server: Targeted Performance in High-Volume Tables\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.sqltabletalk.com\/#website\",\"url\":\"https:\/\/www.sqltabletalk.com\/\",\"name\":\"SQL Table Talk\",\"description\":\"Breaking Down SQL Server, One Post at a Time.\",\"publisher\":{\"@id\":\"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/1947e42a9438bccd91691d8b791888e0\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.sqltabletalk.com\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":[\"Person\",\"Organization\"],\"@id\":\"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/1947e42a9438bccd91691d8b791888e0\",\"name\":\"Stephen Planck\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/64181114edc3de3d99072c049bcec024f025c9536dc89fc8ff1bac58976ca81e?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/64181114edc3de3d99072c049bcec024f025c9536dc89fc8ff1bac58976ca81e?s=96&d=mm&r=g\",\"caption\":\"Stephen Planck\"},\"logo\":{\"@id\":\"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/image\/\"},\"sameAs\":[\"https:\/\/dexterwiki.com\",\"https:\/\/www.linkedin.com\/in\/stephen-planck-4611b692?trk=people-guest_people_search-card&challengeId=AQErf8gbBmcVMwAAAYsyIsxO-0UvU8z7cHrBpZoo_n3xt9qEKpRN5B_jd_LmAMu-OfeArkQ7GDjobJ2uRoQQV35EQdh_rR6kxA&submissionId=09de7067-c335-8e17-40b8-8dc32b60ed6c&challengeSource=AgEcUCw35zpPmAAAAYsyI4vAWhJTV7Nt4vZYKc3V1qiDBpCkKgUvtlOBgYXcE84&challegeType=AgE_wZiTT09IAQAAAYsyI4vDmNvbZIYe6XHju5V2bXVvM3IVxnJslgY&memberId=AgESFTkUShzs_gAAAYsyI4vGYk0Gic1uc5kB6cKOABA26Gw&recognizeDevice=AgHdSZyUSI5CEwAAAYsyI4vKd_koF9JgpsCJShT8QfbK1QMiv8SI\",\"https:\/\/www.youtube.com\/linuxmate\"],\"url\":\"https:\/\/www.sqltabletalk.com\/?author=1\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Filtered Indexes in SQL Server: Targeted Performance in High-Volume Tables - SQL Table Talk","description":"When a table holds millions of rows yet most queries touch only a small, well-defined subset, a traditional non-clustered index feels like using a searchlight to find something sitting under a desk lamp: the index still stores an entry for every row even though the workload rarely needs most of them. SQL Server\u2019s answer is the filtered index\u2014introduced in SQL Server 2008 and still under-used today\u2014allowing you to index just the rows that match a predicate you supply in a WHERE clause.","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.sqltabletalk.com\/?p=1029","og_locale":"en_US","og_type":"article","og_title":"Filtered Indexes in SQL Server: Targeted Performance in High-Volume Tables - SQL Table Talk","og_description":"When a table holds millions of rows yet most queries touch only a small, well-defined subset, a traditional non-clustered index feels like using a searchlight to find something sitting under a desk lamp: the index still stores an entry for every row even though the workload rarely needs most of them. SQL Server\u2019s answer is the filtered index\u2014introduced in SQL Server 2008 and still under-used today\u2014allowing you to index just the rows that match a predicate you supply in a WHERE clause.","og_url":"https:\/\/www.sqltabletalk.com\/?p=1029","og_site_name":"SQL Table Talk","article_published_time":"2025-05-27T14:00:00+00:00","author":"Stephen Planck","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Stephen Planck","Est. reading time":"5 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.sqltabletalk.com\/?p=1029#article","isPartOf":{"@id":"https:\/\/www.sqltabletalk.com\/?p=1029"},"author":{"name":"Stephen Planck","@id":"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/1947e42a9438bccd91691d8b791888e0"},"headline":"Filtered Indexes in SQL Server: Targeted Performance in High-Volume Tables","datePublished":"2025-05-27T14:00:00+00:00","mainEntityOfPage":{"@id":"https:\/\/www.sqltabletalk.com\/?p=1029"},"wordCount":944,"commentCount":2,"publisher":{"@id":"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/1947e42a9438bccd91691d8b791888e0"},"keywords":["database tuning","filtered index","high-volume tables","index maintenance","index optimization","non-clustered index","predicate filtering","query performance","SQL Server","statistics"],"articleSection":["Indexing","Locking","Performance","Query Optimization","Statistics"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.sqltabletalk.com\/?p=1029#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.sqltabletalk.com\/?p=1029","url":"https:\/\/www.sqltabletalk.com\/?p=1029","name":"Filtered Indexes in SQL Server: Targeted Performance in High-Volume Tables - SQL Table Talk","isPartOf":{"@id":"https:\/\/www.sqltabletalk.com\/#website"},"datePublished":"2025-05-27T14:00:00+00:00","description":"When a table holds millions of rows yet most queries touch only a small, well-defined subset, a traditional non-clustered index feels like using a searchlight to find something sitting under a desk lamp: the index still stores an entry for every row even though the workload rarely needs most of them. SQL Server\u2019s answer is the filtered index\u2014introduced in SQL Server 2008 and still under-used today\u2014allowing you to index just the rows that match a predicate you supply in a WHERE clause.","breadcrumb":{"@id":"https:\/\/www.sqltabletalk.com\/?p=1029#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.sqltabletalk.com\/?p=1029"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.sqltabletalk.com\/?p=1029#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.sqltabletalk.com\/"},{"@type":"ListItem","position":2,"name":"Filtered Indexes in SQL Server: Targeted Performance in High-Volume Tables"}]},{"@type":"WebSite","@id":"https:\/\/www.sqltabletalk.com\/#website","url":"https:\/\/www.sqltabletalk.com\/","name":"SQL Table Talk","description":"Breaking Down SQL Server, One Post at a Time.","publisher":{"@id":"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/1947e42a9438bccd91691d8b791888e0"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.sqltabletalk.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":["Person","Organization"],"@id":"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/1947e42a9438bccd91691d8b791888e0","name":"Stephen Planck","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/64181114edc3de3d99072c049bcec024f025c9536dc89fc8ff1bac58976ca81e?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/64181114edc3de3d99072c049bcec024f025c9536dc89fc8ff1bac58976ca81e?s=96&d=mm&r=g","caption":"Stephen Planck"},"logo":{"@id":"https:\/\/www.sqltabletalk.com\/#\/schema\/person\/image\/"},"sameAs":["https:\/\/dexterwiki.com","https:\/\/www.linkedin.com\/in\/stephen-planck-4611b692?trk=people-guest_people_search-card&challengeId=AQErf8gbBmcVMwAAAYsyIsxO-0UvU8z7cHrBpZoo_n3xt9qEKpRN5B_jd_LmAMu-OfeArkQ7GDjobJ2uRoQQV35EQdh_rR6kxA&submissionId=09de7067-c335-8e17-40b8-8dc32b60ed6c&challengeSource=AgEcUCw35zpPmAAAAYsyI4vAWhJTV7Nt4vZYKc3V1qiDBpCkKgUvtlOBgYXcE84&challegeType=AgE_wZiTT09IAQAAAYsyI4vDmNvbZIYe6XHju5V2bXVvM3IVxnJslgY&memberId=AgESFTkUShzs_gAAAYsyI4vGYk0Gic1uc5kB6cKOABA26Gw&recognizeDevice=AgHdSZyUSI5CEwAAAYsyI4vKd_koF9JgpsCJShT8QfbK1QMiv8SI","https:\/\/www.youtube.com\/linuxmate"],"url":"https:\/\/www.sqltabletalk.com\/?author=1"}]}},"jetpack_featured_media_url":"","jetpack-related-posts":[],"jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=\/wp\/v2\/posts\/1029","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1029"}],"version-history":[{"count":1,"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=\/wp\/v2\/posts\/1029\/revisions"}],"predecessor-version":[{"id":1030,"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=\/wp\/v2\/posts\/1029\/revisions\/1030"}],"wp:attachment":[{"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1029"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1029"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sqltabletalk.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1029"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}