The PostgreSQL team announced recently a new release of the most advanced\nopen source relational database - PostgreSQL 12. As usual it comes with an impressive list of improvements\n(generated columns ♥️), one of them being long awaited by dozens of developers: improved Common Table Expressions.
\nI should first explain what are the Common Table Expressions for those who are unfamiliar with them:\nthe CTE’s, often called “WITH queries”, are SQL constructs giving a possibility of creating temporal data views for a sake of a query execution.
Essentially CTE is an additional query which results can be referenced in the subsequent CTE’s or the main query before which\nit is being placed. It should be clear enough with an example - here’s a sample query with two CTE’s taken from Postgres docs:
\nWITH regional_sales AS (\n SELECT region, SUM(amount) AS total_sales\n FROM orders\n GROUP BY region\n), top_regions AS (\n SELECT region\n FROM regional_sales\n WHERE total_sales > (SELECT SUM(total_sales)/10 FROM regional_sales)\n)\nSELECT region,\n product,\n SUM(quantity) AS product_units,\n SUM(amount) AS product_sales\nFROM orders\nWHERE region IN (SELECT region FROM top_regions)\nGROUP BY region, product;Now we know what they are, but what purpose can they serve us? Well - we could parry here and say: for the same purpose as ordinary database views serve.\nThat’s of course a dramatic simplification - CTE’s are much more powerful and should not be treated as a simple database views.\nNevertheless I would like to keep the collation for the sake of this article.
\nDatabase views are absolutely optional - one can simply substitute them with a subquery and achieve identical results.\nIndeed that’s what modern database engines do these days - once a database view is being used they inline it’s query as a subquery.\nWhy to bother then? We are able to deal completely without database views and even if we did use one the database engine would get rid of it anyway.
\nWhat benefits do views give us then? And why the heck are they inlined?
\nThe most appropriate explanation here is that database views help us achieve better readability.\nThey offer an elegant way of abstracting some parts of a database into a meaningful object, often matching closely with the domain.
\nInstead of creating giant and ugly looking queries it is possible to extract some of its parts into an appealing view which is easier to browse and select data from. \"Divide and conquer\" rule in it’s true form.
\nStill, we didn’t answer the fact that the underlying view’s query is most of the times inlined while it is being referenced. The reason is performance of course. Smart guys found out that lazy evaluation helps the optimizer a lot - by delaying the execution we could take advantage of a context of the actual query.
\nThis in turn allows many clever optimization techniques, like: pushing down predicates (WHERE filters), eliminating unnecessary JOINS, accessing only subset of columns etc.\nIn other words - a database is smart enough to do as little work as possible when evaluating database views, in the context of the issued query.
\nPersonally I love this pattern: aggregating all the data into views and letting a database to optimize my queries - these folks are really good in it and my queries are dead simple too.
\nI have mentioned the CTE’s at the beginning, saying they are able to create temporal data views. I still conform to the comparison with database views - they both are in many cases similar.\nThe main difference is that CTE results are temporary and are reachable only in the context of a query which CTE is being part of.
\nIt may make sense to use a CTE in a place where a regular database view is not justified (e.g. it makes sense only in the context of a query and not in the whole domain), expecting similar behavior.
\nBesides many remarkable advantages there’s at least one disadvantage which disqualifies CTE's for most use cases - before PostgreSQL 12 it was implemented as an optimization fence. What does it mean?
\nEasy to imagine an example with a generic data view aggregating lots of data. If the view is then used to select just few records it could mean a tremendous waste of computation, if the aggregation is executed immediately.\nInstead the aggregation should be executed only on a small subset of data, which can be deduced from the outer query.
\nUnfortunately such counter intuitive behavior was true for CTE’s for a long time - their results were materialized only to be accessible for the rest of the query afterwards.
\nNot to blame anybody - the creators had quite good reasons to implement such behavior (i.e. guarantee of exactly one evaluation, possibility of a recursive CTE’s and more) but this still feels like focusing on corner cases instead of optimizing the happy path.\nThat’s why the community insisted for a long time for changing the status quo by giving the possibility of disabling the fence and unlocking the full potential of CTE’s.
\nThe SQL gods listen to their prayers and here it is - PostgreSQL 12 with updated Common Table Expressions.\nBy default, when few constraints are met, the queries will be inlined allowing joint optimizations.
\nIt is still possible to force the old behavior - by defining the CTE AS MATERIALIZED the engine would execute it immediately.\nIt is also possible to hint the optimizer that we definitely want the CTE to be inlined, e.g. when the CTE is being referenced twice the engine won't inline it by default.
This is truly a game changer for many developers who care about their queries’ readability, allowing them to substitute not very well liked subqueries with elegant “WITH queries”.
Don’t get me wrong - not every subquery should be immediately replaced, they still have their strengths and in some cases they should be chosen over CTE’s. It is just convenient to have two distinct tools in a toolbox, isn’t it?
","fields":{"slug":"/postgres12-a-precious-release/","tags":["postgres","postgres12","release","sql","cte"]}}},{"node":{"id":"24fd2709-272a-5811-a69c-7100924de21c","frontmatter":{"category":"Coding","title":"Serving JSON (almost) directly from database","date":"2019-10-29","summary":"Learn how to query JSON data from Postgres 12 to improve Java application's performance.","thumbnail":{"relativePath":"pages/serving-json-from-postgres/liberty.jpg","childImageSharp":{"resolutions":{"base64":"data:image/jpeg;base64,/9j/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhCY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2P/wgARCAAUABQDASIAAhEBAxEB/8QAGAABAAMBAAAAAAAAAAAAAAAAAAIDBAX/xAAUAQEAAAAAAAAAAAAAAAAAAAAA/9oADAMBAAIQAxAAAAHryz0HUYxXEAP/xAAbEAABBAMAAAAAAAAAAAAAAAABAgMSIhAgIf/aAAgBAQABBQJw0SoKxLjVDPT/xAAUEQEAAAAAAAAAAAAAAAAAAAAg/9oACAEDAQE/AR//xAAUEQEAAAAAAAAAAAAAAAAAAAAg/9oACAECAQE/AR//xAAYEAACAwAAAAAAAAAAAAAAAAABIQAQIP/aAAgBAQAGPwJRGzn/xAAaEAEAAwADAAAAAAAAAAAAAAABABEhEDGB/9oACAEBAAE/IVEqq3yWWlcbozCOmOokIz//2gAMAwEAAgADAAAAEOAPAP/EABQRAQAAAAAAAAAAAAAAAAAAACD/2gAIAQMBAT8QH//EABQRAQAAAAAAAAAAAAAAAAAAACD/2gAIAQIBAT8QH//EABwQAQADAQADAQAAAAAAAAAAAAEAETEhQXGhwf/aAAgBAQABPxBIyYq1CL8uc5XU14YIGwTYJTDeFrX2G/k7OwjIAbIBek//2Q==","width":325,"height":325,"src":"/static/e0de7302edcea3d0b0c19a9d147b547a/a2998/liberty.jpg","srcSet":"/static/e0de7302edcea3d0b0c19a9d147b547a/a2998/liberty.jpg 1x,\n/static/e0de7302edcea3d0b0c19a9d147b547a/99cce/liberty.jpg 1.5x,\n/static/e0de7302edcea3d0b0c19a9d147b547a/6e995/liberty.jpg 2x,\n/static/e0de7302edcea3d0b0c19a9d147b547a/968b1/liberty.jpg 3x"}}},"authorName":"Mariusz Nowak","authorDescription":"Mariusz is a Senior Software Engineer at AUTO1 Group.","authorAvatar":null,"headerImage":null},"html":"RESTful API’s are ruling the industry nowadays. They are very often associated with an extremely popular data format - JSON.\nIt is so popular that database creators decided to implement it directly in the database engines.\nAll modern databases offer JSON processing capabilities.\nLet’s have a look and see how can we make use of them to improve our application’s performance.
\nThe typical choice for a Java application is to use JPA as the persistence layer abstraction.\nIt became the de-facto standard for a reason - it offers great flexibility and ease of use.\nUnfortunately it doesn't come without a price since we have to pay with degraded performance.
\nIt is a widely known fact that ORM’s impact performance, compared to pure JDBC.\nOn the other hand, relatively few are willing to use plain JDBC, considering the amount of additional work it requires.
\nLet me demonstrate how to use JDBC to leverage the performance, with the help of modern Postgres features.
\nI have prepared a demo application running on Spring Boot which exposes example data from the northwind database.\nThe data are exposed in three different ways.
\nThe baseline version simply exposes JPA entities:
\n@GetMapping(path = \"/v1/orders/{order_id}\",\n produces = APPLICATION_JSON_VALUE)\npublic Order getEntity(@PathVariable(\"order_id\") Integer orderId) {\n return orderRepository.findById(orderId).orElseThrow();\n}The Order entity aggregates data from numerous database tables: orders, order_details, products, customers, customer_customer_demo and customer_demographics.\nYou could check the corresponding JPA mapping here.
Thanks to the magic of Spring the entity is being translated into a JSON response:
\n{\n \"orderId\": 10284,\n \"employeeId\": 4,\n \"orderDate\": \"1996-08-19\",\n \"requiredDate\": \"1996-09-16\",\n \"shippedDate\": \"1996-08-27\",\n \"shipVia\": 1,\n \"freight\": 76.56,\n \"shipName\": \"Lehmanns Marktstand\",\n \"shipAddress\": \"Magazinweg 7\",\n \"shipCity\": \"Frankfurt a.M.\",\n \"shipRegion\": null,\n \"shipPostalCode\": \"60528\",\n \"shipCountry\": \"Germany\",\n \"orderDetails\": [\n {\n \"orderId\": 10284,\n \"productId\": 27,\n \"product\": {\n \"productId\": 27,\n \"categoryId\": 3,\n \"supplierId\": 11,\n \"productName\": \"Schoggi Schokolade\",\n \"discontinued\": false,\n \"quantityPerUnit\": \"100 - 100 g pieces\",\n \"unitPrice\": 43.9,\n \"unitsInStock\": 49,\n \"unitsOnOrder\": 0,\n \"reorderLevel\": 30\n },\n \"unitPrice\": 35.1,\n \"quantity\": 15,\n \"discount\": 0.25\n },\n {...},\n {...},\n {...}\n ],\n \"customer\": {\n \"customerId\": \"LEHMS\",\n \"companyName\": \"Lehmanns Marktstand\",\n \"contactName\": \"Renate Messner\",\n \"contactTitle\": \"Sales Representative\",\n \"address\": \"Magazinweg 7\",\n \"city\": \"Frankfurt a.M.\",\n \"region\": null,\n \"postalCode\": \"60528\",\n \"country\": \"Germany\",\n \"phone\": \"069-0245984\",\n \"fax\": \"069-0245874\",\n \"customerDesc\": [\n {\n \"customerTypeId\": \"AAAA\",\n \"customerDesc\": \"First demographic\"\n },\n {...},\n {...},\n {...}\n ]\n }\n}The demo project includes the p6spy library which gives an insight into the queries being issued against database.\nTurns out that three queries are required to load a particular Order - this means three database round trips.
\nOf course we can force the ORM to join all the tables and fetch them in one hop, but this seems a not so elegant solution -\nit pushes the ORM to load duplicated data and the necessity of deduplicating them in-memory. Can we do better?
\nJDBC is always a choice if the solution could be expressed via SQL query. Luckily we can create one which matches our case perfectly:
\nWITH products(\"productId\", \"categoryId\", \"supplierId\", \"productName\", \"discontinued\", \"quantityPerUnit\",\n \"unitPrice\", \"unitsInStock\", \"unitsOnOrder\", \"reorderLevel\") AS\n (SELECT p.product_id,\n p.category_id,\n p.supplier_id,\n p.product_name,\n p.discontinued::boolean,\n p.quantity_per_unit,\n p.unit_price,\n p.units_in_stock,\n p.units_on_order,\n p.reorder_level\n FROM products p),\n orderDetails(\"orderId\", \"productId\", \"product\", \"unitPrice\", \"quantity\", \"discount\") AS\n (SELECT d.order_id,\n d.product_id,\n (SELECT to_json(p) FROM products p WHERE p.\"productId\" = d.product_id),\n d.unit_price,\n d.quantity,\n d.discount\n FROM order_details d),\n\n demographics(\"customerId\", \"customerTypeId\", \"customerDesc\") AS\n (SELECT ccd.customer_id,\n ccd.customer_type_id,\n cd.customer_desc\n FROM customer_demographics cd\n JOIN customer_customer_demo ccd on cd.customer_type_id = ccd.customer_type_id),\n customers(\"customerId\", \"companyName\", \"contactName\", \"contactTitle\", \"address\", \"city\", \"region\", \"postalCode\",\n \"country\", \"phone\", \"fax\", \"customerDesc\") AS\n (SELECT c.customer_id,\n c.company_name,\n c.contact_name,\n c.contact_title,\n c.address,\n c.city,\n c.region,\n c.postal_code,\n c.country,\n c.phone,\n c.fax,\n (SELECT to_json(array_agg(to_json(d))) FROM (SELECT \"customerTypeId\", \"customerDesc\" FROM demographics WHERE demographics.\"customerId\" = c.customer_id) d)\n FROM customers c),\n\n orders(\"orderId\", \"employeeId\", \"orderDate\", \"requiredDate\", \"shippedDate\", \"shipVia\", \"freight\",\n \"shipName\", \"shipAddress\", \"shipCity\", \"shipRegion\", \"shipPostalCode\", \"shipCountry\", \"orderDetails\",\n \"customer\") AS\n (SELECT o.order_id,\n o.employee_id,\n o.order_date,\n o.required_date,\n o.shipped_date,\n o.ship_via,\n o.freight,\n o.ship_name,\n o.ship_address,\n o.ship_city,\n o.ship_region,\n o.ship_postal_code,\n o.ship_country,\n (SELECT to_json(array_agg(to_json(d))) FROM orderDetails d WHERE d.\"orderId\" = o.order_id),\n (SELECT to_json(c) FROM customers c WHERE c.\"customerId\" = o.customer_id)\n FROM orders o)\n\nSELECT to_json(orders) AS json_body FROM orders WHERE orders.\"orderId\" = ?The query looks verbose, perhaps a little enigmatic.\nIt is a bit long and therefore it could be overwhelming.\nHowever, on a closer look we could notice it isn't so much complicated - there are few idioms which make the query powerful.
\nThe good news is that the query generates the exact same JSON as the JPA endpoint provides - it is possible thanks to Postgres’ excellent support for JSON format.\nOur case is not sophisticated though - single to_json function is enough to deal with JSON objects and arrays.
One can notice how the nesting has been realized: how to nest JSON objects and JSON arrays, e.g. the orderDetails or the customer into order).\nThe simple idiom (accordingly to_json(...) or to_json(array_agg(to_json(...)))) does the job.
The database query could be adapted according to the caller needs - the response can be shrinked, making the query simpler and - most probably - even more effective.
\nWorth noticing is that the join table customer_customer_demo has been mitigated in the end result, just like the JPA version does by using @ManyToMany.
\n\nThe query is flexible enough to substitute all JPA features we need.
\n
I want also emphasize the fact of CTE’s being used to decompose the query into logical parts.\nPersonally I find it elegant because it is easy on the eyes and it “scales” - meaning while our case gets more complicated (JSON aggregates more data, becomes deeply nested) our query gets longer instead of getting deeper.\nIf the query grows too long we can simplify it by extracting some it’s parts as database views.
\nThe CTE has one more advantage here: it gives a control over the keys visible in end resulting JSON (order_id becomes orderId).
So we have a nice query which allows us to fetch required data in one hop in a format ready to be consumed by our clients.\nThis means no adjustments are required, therefore the Java implementation can be that easy:
\n@SneakyThrows\n@GetMapping(path = \"/v2/orders/{order_id}\",\n produces = APPLICATION_JSON_VALUE)\npublic String getRawBodyFromDatabase(\n @PathVariable(\"order_id\") Integer orderId) {\n return jdbcTemplate.query(JSON_QUERY, (ResultSet rs) -> {\n rs.next();\n return rs.getString(1);\n }, orderId);\n}We didn’t use plain JDBC here but a JdbcTemplate which has a negligible overhead and it simplifies our code.
Of course we could achieve similar results using plain JDBC (e.g. by using PreparedStatement directly) - without the use of Spring.\nEven then the necessity of extracting only a single field from the result set makes the solution less coarse than using JDBC in a usual way\n(in our case it would require managing at least three result sets).\nAll the complexity has been moved down into the query.
Some folks could argue “I don’t want the JSON to be directly returned - I definitely need the POJO to make some processing over it”.\nThat's an absolutely fair statement! We can satisfy this requirement as well.
\nLet’s point it one more time: our query produces the exact same JSON as the Order JPA entity has been translated into.
\nThis means we can use the resulting JSON and unmarshall it into an object of class Order.\nOf course the object won’t be tracked by the JPA whatsoever but we don’t need these capabilities - remember: we are serving persisted data and not mutating them.
@SneakyThrows\n@GetMapping(path = \"/v3/orders/{order_id}\",\n produces = APPLICATION_JSON_VALUE)\npublic Order getEntityNotUsingJpa(@PathVariable(\"order_id\") Integer orderId) {\n return jdbcTemplate.query(JSON_QUERY, (ResultSet rs) -> {\n rs.next();\n return unmarshall(rs.getString(1), Order.class);\n }, orderId);\n}\n\n@SneakyThrows\nprivate <T> T unmarshall(String json_body, Class<T> clazz) {\n return objectMapper.readValue(json_body, clazz);\n}This version is very similar to V2 but it introduces an additional step of unmarshalling.\nIt is also a great verification step which makes us sure the V1 and V2 results are identical.
\nSo how are all the solutions performing?\nWe suspect the V2 version to be faster than the competitors.\nWe are also unsure about the V3 which requires additional unmarshalling phase - could it impact the performance badly?
\nThe demo project includes a JMeter configuration and a bash script which verifies the configurations.\nThe benchmark is always run against a fresh setup (db + app).\nThe app is running on java 11 with EpsilonGC turned on - this allows us to verify memory consumption of each solution.
\nThe requests are run in strictly defined sequence, fetching the orders one by one.\nThere’s a prewarming phase which issues 100 requests and then a profiling phase with 20k of requests.
\nI have run the benchmark several times on a Macbook Pro 2018, the results are similar on each run.\nHere’s a summary of the most recent run:
\nWe can see the V2 outperforming the V1 by 32 seconds - that’s 37% improvement.
\nWe can notice also a lower memory consumption on the V2 - it used 52 MB (49 MiB) less memory than V1\n(noted the initial app’s memory usage which is 785 MB):
\n\n\nWorth noticing: the V2 version does not leverage Hibernate at all therefore we could minimize the memory footprint even more by excluding the JPA dependencies.
\n
Let’s have a look at response times:
\nOnce again we are able to notice improved throughput as well as lower latency.
\nThe plot confirms that as well (cropped for brevity):
\nPersonally I am very well satisfied with the V3 results - the memory consumption being at the same level as the JPA it still offers satisfying performance, nearly as good as the V1.\nIt proves that the unmarshalling does not impact the performance as badly as we might expect.
\nI really encourage readers try running the benchmark and share their own results!
\nLast words about the database: the results are reproducible currently only on Postgres 12,\ndue to recent improvements in Common Table Expressions.
\nI have had a run on Postgres 11 and the V2’s performance was… horrible - I had to shorten the benchmark 10 times to make it finish in a reasonable time.\nHere are the results I got:
\nYou can give it a try - the demo app is prepared to allow a quick switch to Postgres 11.
\nThe query we have prepared enables fine control over the data being fetched from database.
\nWe are no longer restricted to tabular data - we could easily fetch complex data graphs, even manipulate them to match the desired format.\nWe did it keeping the solution maintainable and very effective in terms of throughput.
\nIt is still unknown to me what is the main source of latency in the JPA version: either is it the additional round trips or the internals of Hibernate.\nI see the topic interesting to explore.\nPerhaps some day we’ll get an ORM which is able to load entity graphs using a single query.\nAny Hibernate devs reading here?
","fields":{"slug":"/serving-json-from-postgres/","tags":["jdbc","jpa","postgres12","json","spring boot"]}}}]}},"pageContext":{"slug":"/tags/postgres12","tag":"postgres12","categories":["Architecture","Coding","DevOps","Engineering","ProjectManagement","QA","Social","TechRadar"]}}