{"id":930,"date":"2012-04-29T16:31:29","date_gmt":"2012-04-29T20:31:29","guid":{"rendered":"http:\/\/sqlity.net\/en\/?p=930"},"modified":"2014-11-13T13:59:00","modified_gmt":"2014-11-13T18:59:00","slug":"the-unloved-backward-scan","status":"publish","type":"post","link":"https:\/\/sqlity.net\/en\/930\/the-unloved-backward-scan\/","title":{"rendered":"The Unloved Backward Scan"},"content":{"rendered":"
\n

Introduction<\/h3>\n

\nWhen a query requires rows to be sorted, either directly requested with an ORDER BY<\/span> clause or because one of the iterators requires it, SQL Server has two options to guarantee that order. The obvious one is to utilize a sort iterator. If the data comes from an index (clustered or covering), SQL Server can also use an \"Ordered Scan\" of the data. Depending on the requested sort direction, such an ordered scan can be either forward or backward.\n<\/p>\n

\nThis would hardly be worth an article, if there wasn't the peculiarity that SQL Server obviously does not like the idea of having to execute an ordered scan that is directed backwards.\n<\/p>\n

Backward Scan Dislike<\/h3>\n

\nLet's look at an example. First we need some tables with data:\n<\/p>\n

\n[sql]\nIF OBJECT_ID('dbo.T1') IS NOT NULL DROP TABLE dbo.T1;
\nIF OBJECT_ID('dbo.T2') IS NOT NULL DROP TABLE dbo.T2;<\/p>\n

CREATE TABLE dbo.T1(
\nId INT CONSTRAINT T1_PK PRIMARY KEY CLUSTERED,
\nv1 INT,
\nc1 VARCHAR(8000)
\n);<\/p>\n

CREATE TABLE dbo.T2(
\nId INT CONSTRAINT T2_PK PRIMARY KEY CLUSTERED,
\nv1 INT,
\nc1 VARCHAR(8000)
\n);<\/p>\n

INSERT INTO dbo.T1(Id,v1,c1)
\nSELECT n,CHECKSUM(NEWID()),'*'
\nFROM dbo.GetNums(1000000);<\/p>\n

INSERT INTO dbo.T2(Id,v1,c1)
\nSELECT n,CHECKSUM(NEWID()),'*'
\nFROM dbo.GetNums(1000000);
\n--Get dbo.GetNums here: http:\/\/www.sqlmag.com\/article\/sql-server\/virtual-auxiliary-table-of-numbers
\n[\/sql]\n<\/p><\/div>\n

\nThis script is creating two tables containing one million rows each. The v1 column is filled with random values; the c1 column just contains a single constant character. The Id column is the clustered primary key and it is providing the ordering on disk that we are going to use.\n<\/p>\n

\nThe query is a little made up. It joins T2 to itself bringing back only one set of columns. It also restricts the result of this join to the first one million rows, sorted by T2.Id. The one million values in T2.v1 are random from a set of 4 billion making them \"mostly\" unique. That means the self-join is expected to return about one million rows anyway. Those rows are then joined to T1. In the end the ORDER BY<\/span> requests that all rows be returned sorted by the Id column of the T1 table:\n<\/p>\n

\n[sql]\nSELECT *
\nFROM dbo.T1 A
\n INNER JOIN ( SELECT TOP ( 1000000 )
\n B.*
\n FROM dbo.T2 B
\n INNER JOIN dbo.T2 C ON B.v1 = C.v1
\n ORDER BY B.Id
\n ) BC ON A.Id = BC.Id
\nORDER BY A.Id;
\n[\/sql]\n<\/div>\n

\nThe execution plan of this query looks like this:\n<\/p>\n

\n\"Plan<\/a>\n<\/p>\n

\nThere is nothing unexpected in this plan. The T2 self-join is done with a hash join operator, as there is no index on the v1 column. The data is then sorted by a sort operator and passed through a serial zone for the top operator. After that there is no additional sort operator for the data to pass through. As the merge join requires both streams to be sorted the same way on the join column, this means that the data must be produced sorted by the scan of the T1 table. A quick look at its properties confirms that:\n<\/p>\n

\n\"Forward<\/a>\n<\/p>\n

\nThis scan is a forward scan, as both ORDER BY<\/span> statements are asking to sort by Id ascending. To make this scan go backwards we should just have to change the query to sort by Id descending in both places:\n<\/p>\n

\n[sql]\nSELECT *
\nFROM dbo.T1 A
\n INNER JOIN ( SELECT TOP ( 1000000 )
\n B.*
\n FROM dbo.T2 B
\n INNER JOIN dbo.T2 C ON B.v1 = C.v1
\n ORDER BY B.Id DESC
\n ) BC ON A.Id = BC.Id
\nORDER BY A.Id DESC;
\n[\/sql]\n<\/div>\n

\n However, this query produces this rather unexpected plan:\n<\/p>\n

\n\"Backward<\/a>\n<\/p>\n

\nA loop join with an index seek against the T1 table to retrieve 1,000,000 single rows – that cannot be good.\n<\/p>\n

\nBefore we look at execution statistics let's force the merge join back by specifying a join hint:\n<\/p>\n

\n[sql]\nSELECT *
\nFROM dbo.T1 A
\n INNER MERGE JOIN ( SELECT TOP ( 1000000 )
\n B.*
\n FROM dbo.T2 B
\n INNER JOIN dbo.T2 C ON B.v1 = C.v1
\n ORDER BY B.Id DESC
\n ) BC ON A.Id = BC.Id
\nORDER BY A.Id DESC;
\n[\/sql]\n<\/div>\n

\n Now we get the expected plan again:\n<\/p>\n

\n\"Merge<\/a>\n<\/p>\n

\nIf you compare the properties for the iterators in the forward scan and the backward scan plan you will notice, that the cost of the two scan directions is not that much different:\n<\/p>\n

\n\"Backward<\/a>\n<\/p>\n

\nThe estimated cost of the scan iterator is 0% in both cases. The bulk of the work is done in the hash self-join and the following sort of the T2 table.\n<\/p>\n

\nSo, let us take a look at the execution statistics of all three queries:\n<\/p>\n

\n\"Query<\/a>\n<\/p>\n

\nThe execution statistics clearly show that the decision to go with a loop join was not necessarily the best. While the estimated cost for the backward scan is about 150% of the estimated cost for the loop join, the actual reads for the loop join version are about 3 million, which is more than 250 times higher than the 8000 reads for either scan direction.\n<\/p>\n

Disk Access<\/h3>\n

\nTo understand were this dislike is coming from we need to look at the access pattern necessary to retrieve the data from disk. A forward scan of a table (or index), that is not heavily fragmented, looks pretty much like doing a single contiguous read of a big blob of data. SQL Server has a lot of performance optimizations build in that make this type of access as fast as possible. The Read-Ahead mechanism is a good example for that.\n<\/p>\n

\nA backward scan on the other hand looks quite the opposite: After reading a page, the disk has to do almost a complete turn to get to the previous page, which is the next one in line to be read. This is about the worst kind of random access you can come by.\n<\/p>\n

\nAs SQL Server always assumes that none of the requested pages are in cache, the decision to not get into that backward spinning game seems quite understandable.\n<\/p>\n

\nAlso, if you closely compare the two \"scanning\" execution plans you will notice that while the forward scan iterator is parallelized, the backward scan operator is executed single threaded. This is a general rule: SQL Server cannot execute a backward scan in parallel. That makes sense as with all that waiting for the disk to do another spin to get to the \"next\" page, it is unlikely for the data to come in quickly enough to keep multiple threads busy.\n<\/p>\n

Estimates?<\/h3>\n

\nBut wait, there is one more thing: If you look at the image above and compare the properties of all iterators in the two scanning plans, you will notice something odd. The estimated CPU cost of the \"hash match inner join\" iterator goes from 11 in the \"forward\" case to 1357 in the \"backward\" case; the estimated IO cost makes a similar jump from 0 to 1654. That seems to not make a lot of sense, as the next iterator, the sort, is a blocking iterator. \"Blocking\" means that the iterator reads in all<\/u> input rows into a holding area before producing any output rows. This implies that anything on the left side of a sort should not be able to influence the cost of operators on the right side of it. That is, unless it affects the number of rows significantly, as this is a TOP N Sort. See TOP N Sort \u2013 A Little Bit of Sorting <\/a> for an explanation. But as in this example all columns are \"mostly\" unique, the optimizer guesses correctly that about one million rows get passed into the hash join on each input and also about one million rows come out the other end. So row count estimates should not matter here.\n<\/p>\n

\nIf you look at the estimates when executing just that inner query sorting backwards, you will see that they exactly match the ones in the imbedded forward sorting case:\n<\/p>\n

\n\"Iterator<\/a>\n<\/p>\n

\nThat means that the scan direction change of the T1 table causes the estimates on the other side of the merge join to get completely thrown off.\n<\/p>\n

Conclusion<\/h3>\n

\nSQL Servers dislike of backward scan operations is understandable when looking at the work necessary to retrieve the records from disk in opposite index order. Additionally, a backward scan cannot be executed in parallel. That adds to the list of reasons, why the backward scan seems unloved.\n<\/p>\n

\nHowever, the main reason why SQL Server avoids backward scans seems to be that they throw its cost estimations off, making following iterators appear a lot more expensive than they really are.\n<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

\nWhen a query requires rows to be sorted, either directly requested with an [tt]ORDER BY[\/tt] clause or because one of the iterators requires it, SQL Server has two options to guarantee that order. The obvious one is to utilize a sort iterator. If the data comes from an index (clustered or covering), SQL Server can also use an “Ordered Scan” of the data. Depending on the requested sort direction, such an ordered scan can be either forward or backward.\n<\/p>\n

\nThis would hardly be worth an article, if there wasn’t the peculiarity that SQL Server obviously does not like the idea of having to execute an ordered scan that is directed backwards.\n<\/p>\n

[more…]<\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[5,19,14],"tags":[],"class_list":["post-930","post","type-post","status-publish","format-standard","hentry","category-general","category-performance","category-sql-server-internals"],"acf":[],"yoast_head":"\nThe Unloved Backward Scan - sqlity.net<\/title>\n<meta name=\"description\" content=\"To guarantee row order, SQL Server can utilize an ordered scan reading forward or backward. However, SQL Server dislikes the backward scan\u2026\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/sqlity.net\/en\/930\/the-unloved-backward-scan\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"The Unloved Backward Scan - sqlity.net\" \/>\n<meta property=\"og:description\" content=\"To guarantee row order, SQL Server can utilize an ordered scan reading forward or backward. However, SQL Server dislikes the backward scan\u2026\" \/>\n<meta property=\"og:url\" content=\"https:\/\/sqlity.net\/en\/930\/the-unloved-backward-scan\/\" \/>\n<meta property=\"og:site_name\" content=\"sqlity.net\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/sqlity.net\" \/>\n<meta property=\"article:published_time\" content=\"2012-04-29T20:31:29+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2014-11-13T18:59:00+00:00\" \/>\n<meta property=\"og:image\" content=\"http:\/\/sqlity.net\/wp-content\/uploads\/2012\/04\/Plan_with_Forward_Scan.png\" \/>\n<meta name=\"author\" content=\"Sebastian Meine\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@sqlity\" \/>\n<meta name=\"twitter:site\" content=\"@sqlity\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Sebastian Meine\" \/>\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:\\\/\\\/sqlity.net\\\/en\\\/930\\\/the-unloved-backward-scan\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/sqlity.net\\\/en\\\/930\\\/the-unloved-backward-scan\\\/\"},\"author\":{\"name\":\"Sebastian Meine\",\"@id\":\"https:\\\/\\\/sqlity.net\\\/en\\\/#\\\/schema\\\/person\\\/bcffd8c572bc2f1bd10fdba80135e53c\"},\"headline\":\"The Unloved Backward Scan\",\"datePublished\":\"2012-04-29T20:31:29+00:00\",\"dateModified\":\"2014-11-13T18:59:00+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/sqlity.net\\\/en\\\/930\\\/the-unloved-backward-scan\\\/\"},\"wordCount\":1433,\"commentCount\":0,\"image\":{\"@id\":\"https:\\\/\\\/sqlity.net\\\/en\\\/930\\\/the-unloved-backward-scan\\\/#primaryimage\"},\"thumbnailUrl\":\"http:\\\/\\\/sqlity.net\\\/wp-content\\\/uploads\\\/2012\\\/04\\\/Plan_with_Forward_Scan.png\",\"articleSection\":[\"General\",\"Performance\",\"SQL Server Internals\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/sqlity.net\\\/en\\\/930\\\/the-unloved-backward-scan\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/sqlity.net\\\/en\\\/930\\\/the-unloved-backward-scan\\\/\",\"url\":\"https:\\\/\\\/sqlity.net\\\/en\\\/930\\\/the-unloved-backward-scan\\\/\",\"name\":\"The Unloved Backward Scan - sqlity.net\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/sqlity.net\\\/en\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/sqlity.net\\\/en\\\/930\\\/the-unloved-backward-scan\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/sqlity.net\\\/en\\\/930\\\/the-unloved-backward-scan\\\/#primaryimage\"},\"thumbnailUrl\":\"http:\\\/\\\/sqlity.net\\\/wp-content\\\/uploads\\\/2012\\\/04\\\/Plan_with_Forward_Scan.png\",\"datePublished\":\"2012-04-29T20:31:29+00:00\",\"dateModified\":\"2014-11-13T18:59:00+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/sqlity.net\\\/en\\\/#\\\/schema\\\/person\\\/bcffd8c572bc2f1bd10fdba80135e53c\"},\"description\":\"To guarantee row order, SQL Server can utilize an ordered scan reading forward or backward. However, SQL Server dislikes the backward scan\u2026\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/sqlity.net\\\/en\\\/930\\\/the-unloved-backward-scan\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/sqlity.net\\\/en\\\/930\\\/the-unloved-backward-scan\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/sqlity.net\\\/en\\\/930\\\/the-unloved-backward-scan\\\/#primaryimage\",\"url\":\"http:\\\/\\\/sqlity.net\\\/wp-content\\\/uploads\\\/2012\\\/04\\\/Plan_with_Forward_Scan.png\",\"contentUrl\":\"http:\\\/\\\/sqlity.net\\\/wp-content\\\/uploads\\\/2012\\\/04\\\/Plan_with_Forward_Scan.png\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/sqlity.net\\\/en\\\/930\\\/the-unloved-backward-scan\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/sqlity.net\\\/en\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"The Unloved Backward Scan\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/sqlity.net\\\/en\\\/#website\",\"url\":\"https:\\\/\\\/sqlity.net\\\/en\\\/\",\"name\":\"sqlity.net\",\"description\":\"Quality for SQL\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/sqlity.net\\\/en\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/sqlity.net\\\/en\\\/#\\\/schema\\\/person\\\/bcffd8c572bc2f1bd10fdba80135e53c\",\"name\":\"Sebastian Meine\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/4ab0a6d02dd494849a584a2c3c8bc3bdcef1d0aa5f87e98bf905dbdb9ad2ce3a?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/4ab0a6d02dd494849a584a2c3c8bc3bdcef1d0aa5f87e98bf905dbdb9ad2ce3a?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/4ab0a6d02dd494849a584a2c3c8bc3bdcef1d0aa5f87e98bf905dbdb9ad2ce3a?s=96&d=mm&r=g\",\"caption\":\"Sebastian Meine\"},\"sameAs\":[\"http:\\\/\\\/sqlity.net\",\"https:\\\/\\\/x.com\\\/sqlity\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"The Unloved Backward Scan - sqlity.net","description":"To guarantee row order, SQL Server can utilize an ordered scan reading forward or backward. However, SQL Server dislikes the backward scan\u2026","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:\/\/sqlity.net\/en\/930\/the-unloved-backward-scan\/","og_locale":"en_US","og_type":"article","og_title":"The Unloved Backward Scan - sqlity.net","og_description":"To guarantee row order, SQL Server can utilize an ordered scan reading forward or backward. However, SQL Server dislikes the backward scan\u2026","og_url":"https:\/\/sqlity.net\/en\/930\/the-unloved-backward-scan\/","og_site_name":"sqlity.net","article_publisher":"https:\/\/www.facebook.com\/sqlity.net","article_published_time":"2012-04-29T20:31:29+00:00","article_modified_time":"2014-11-13T18:59:00+00:00","og_image":[{"url":"http:\/\/sqlity.net\/wp-content\/uploads\/2012\/04\/Plan_with_Forward_Scan.png","type":"","width":"","height":""}],"author":"Sebastian Meine","twitter_card":"summary_large_image","twitter_creator":"@sqlity","twitter_site":"@sqlity","twitter_misc":{"Written by":"Sebastian Meine","Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/sqlity.net\/en\/930\/the-unloved-backward-scan\/#article","isPartOf":{"@id":"https:\/\/sqlity.net\/en\/930\/the-unloved-backward-scan\/"},"author":{"name":"Sebastian Meine","@id":"https:\/\/sqlity.net\/en\/#\/schema\/person\/bcffd8c572bc2f1bd10fdba80135e53c"},"headline":"The Unloved Backward Scan","datePublished":"2012-04-29T20:31:29+00:00","dateModified":"2014-11-13T18:59:00+00:00","mainEntityOfPage":{"@id":"https:\/\/sqlity.net\/en\/930\/the-unloved-backward-scan\/"},"wordCount":1433,"commentCount":0,"image":{"@id":"https:\/\/sqlity.net\/en\/930\/the-unloved-backward-scan\/#primaryimage"},"thumbnailUrl":"http:\/\/sqlity.net\/wp-content\/uploads\/2012\/04\/Plan_with_Forward_Scan.png","articleSection":["General","Performance","SQL Server Internals"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/sqlity.net\/en\/930\/the-unloved-backward-scan\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/sqlity.net\/en\/930\/the-unloved-backward-scan\/","url":"https:\/\/sqlity.net\/en\/930\/the-unloved-backward-scan\/","name":"The Unloved Backward Scan - sqlity.net","isPartOf":{"@id":"https:\/\/sqlity.net\/en\/#website"},"primaryImageOfPage":{"@id":"https:\/\/sqlity.net\/en\/930\/the-unloved-backward-scan\/#primaryimage"},"image":{"@id":"https:\/\/sqlity.net\/en\/930\/the-unloved-backward-scan\/#primaryimage"},"thumbnailUrl":"http:\/\/sqlity.net\/wp-content\/uploads\/2012\/04\/Plan_with_Forward_Scan.png","datePublished":"2012-04-29T20:31:29+00:00","dateModified":"2014-11-13T18:59:00+00:00","author":{"@id":"https:\/\/sqlity.net\/en\/#\/schema\/person\/bcffd8c572bc2f1bd10fdba80135e53c"},"description":"To guarantee row order, SQL Server can utilize an ordered scan reading forward or backward. However, SQL Server dislikes the backward scan\u2026","breadcrumb":{"@id":"https:\/\/sqlity.net\/en\/930\/the-unloved-backward-scan\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/sqlity.net\/en\/930\/the-unloved-backward-scan\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/sqlity.net\/en\/930\/the-unloved-backward-scan\/#primaryimage","url":"http:\/\/sqlity.net\/wp-content\/uploads\/2012\/04\/Plan_with_Forward_Scan.png","contentUrl":"http:\/\/sqlity.net\/wp-content\/uploads\/2012\/04\/Plan_with_Forward_Scan.png"},{"@type":"BreadcrumbList","@id":"https:\/\/sqlity.net\/en\/930\/the-unloved-backward-scan\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/sqlity.net\/en\/"},{"@type":"ListItem","position":2,"name":"The Unloved Backward Scan"}]},{"@type":"WebSite","@id":"https:\/\/sqlity.net\/en\/#website","url":"https:\/\/sqlity.net\/en\/","name":"sqlity.net","description":"Quality for SQL","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/sqlity.net\/en\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/sqlity.net\/en\/#\/schema\/person\/bcffd8c572bc2f1bd10fdba80135e53c","name":"Sebastian Meine","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/4ab0a6d02dd494849a584a2c3c8bc3bdcef1d0aa5f87e98bf905dbdb9ad2ce3a?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/4ab0a6d02dd494849a584a2c3c8bc3bdcef1d0aa5f87e98bf905dbdb9ad2ce3a?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/4ab0a6d02dd494849a584a2c3c8bc3bdcef1d0aa5f87e98bf905dbdb9ad2ce3a?s=96&d=mm&r=g","caption":"Sebastian Meine"},"sameAs":["http:\/\/sqlity.net","https:\/\/x.com\/sqlity"]}]}},"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p2wXuw-f0","jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/sqlity.net\/en\/wp-json\/wp\/v2\/posts\/930","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sqlity.net\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sqlity.net\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sqlity.net\/en\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/sqlity.net\/en\/wp-json\/wp\/v2\/comments?post=930"}],"version-history":[{"count":0,"href":"https:\/\/sqlity.net\/en\/wp-json\/wp\/v2\/posts\/930\/revisions"}],"wp:attachment":[{"href":"https:\/\/sqlity.net\/en\/wp-json\/wp\/v2\/media?parent=930"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sqlity.net\/en\/wp-json\/wp\/v2\/categories?post=930"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sqlity.net\/en\/wp-json\/wp\/v2\/tags?post=930"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}