{"id":37975,"date":"2019-10-31T22:20:56","date_gmt":"2019-10-31T19:20:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost\/"},"modified":"2019-10-31T22:20:56","modified_gmt":"2019-10-31T19:20:56","slug":"apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","title":{"rendered":"Mejoras para los perezosos: c\u00f3mo PostgreSQL 12 aumenta el rendimiento","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Mejoras<\/p>\n

PostgreSQL 12<\/a><\/noindex>, la \u00faltima versi\u00f3n de \"la mejor base de datos relacional de c\u00f3digo abierto del mundo\", se lanzar\u00e1 en un par de semanas (si todo sale seg\u00fan lo planeado). Esto se alinea con el calendario habitual: una nueva versi\u00f3n con un mont\u00f3n de nuevas caracter\u00edsticas se lanza una vez al a\u00f1o, y, honestamente, eso es impresionante. Por eso me convert\u00ed en un miembro activo de la comunidad de PostgreSQL.<\/p>\n

<\/p>\n

En mi opini\u00f3n, a diferencia de versiones anteriores, PostgreSQL 12 no incluye una o dos funciones revolucionarias (como la partici\u00f3n o el paralelismo de consultas). Brome\u00e9 diciendo que la principal caracter\u00edstica de PostgreSQL 12 es su mayor estabilidad. \u00bfY no es eso lo que se necesita cuando gestionas datos cr\u00edticos para tu negocio?<\/p>\n

<\/p>\n

Pero PostgreSQL 12 no se detiene ah\u00ed: con nuevas caracter\u00edsticas y mejoras, las aplicaciones funcionar\u00e1n mejor, y solo necesitas hacer una actualizaci\u00f3n.<\/em><\/p>\n

<\/p>\n

(Bueno, tal vez tambi\u00e9n reindexar, pero en esta versi\u00f3n no es tan complicado como sol\u00edamos pensar.)<\/p>\n

<\/a><\/noindex><\/p>\n

Ser\u00eda genial actualizar PostgreSQL y disfrutar inmediatamente de mejoras significativas sin muchas complicaciones. Hace unos a\u00f1os, analic\u00e9 la actualizaci\u00f3n de PostgreSQL 9.4 a PostgreSQL 10 y vi c\u00f3mo se aceler\u00f3 la aplicaci\u00f3n gracias a la mejora del paralelismo de consultas en PostgreSQL 10. Y, lo m\u00e1s importante, casi no se necesitaba nada de mi parte (solo configurar un par\u00e1metro de configuraci\u00f3n. max_parallel_workers<\/code>).<\/p>\n

<\/p>\n

Es c\u00f3modo cuando las aplicaciones funcionan mejor inmediatamente despu\u00e9s de la actualizaci\u00f3n. Y hacemos todo lo posible para complacer a los usuarios, ya que cada vez hay m\u00e1s para PostgreSQL.<\/p>\n

<\/p>\n

\u00bfY c\u00f3mo te har\u00e1 feliz una simple actualizaci\u00f3n a PostgreSQL 12? Te lo cuento ahora.<\/p>\n

<\/p>\n

Mejoras serias en la indexaci\u00f3n<\/h3>\n

<\/p>\n

Sin indexaci\u00f3n, la base de datos no avanzar\u00e1 mucho. \u00bfC\u00f3mo m\u00e1s se puede encontrar informaci\u00f3n r\u00e1pidamente? El sistema de indexaci\u00f3n fundamental de PostgreSQL se llama \u00e1rbol-B<\/a><\/noindex>. Este tipo de \u00edndice est\u00e1 optimizado para sistemas de almacenamiento.<\/p>\n

<\/p>\n

Simplemente usamos el operador CREATE INDEX ON some_table (some_column)<\/code>, y PostgreSQL realiza gran parte del trabajo para mantener el \u00edndice actualizado mientras seguimos insertando, actualizando y eliminando valores. Todo funciona por s\u00ed mismo, como por arte de magia.<\/p>\n

<\/p>\n

Pero los \u00edndices de PostgreSQL tienen un problema: se inflan<\/a><\/noindex> y ocupan espacio adicional en el disco, y el rendimiento de la extracci\u00f3n y actualizaci\u00f3n de datos disminuye. Por \"inflaci\u00f3n\", me refiero a un mantenimiento ineficaz de la estructura del \u00edndice. Esto puede estar, o no estar, relacionado con los tuplas basura que elimina VACUUM<\/a><\/noindex> (gracias a la informaci\u00f3n de Peter Geoghegan (Peter Geoghegan<\/a><\/noindex>)). La inflaci\u00f3n del \u00edndice es especialmente notable en cargas de trabajo donde el \u00edndice se modifica activamente.<\/p>\n

<\/p>\n

PostgreSQL 12 mejora significativamente el rendimiento de los \u00edndices de \u00e1rbol B, y los experimentos con pruebas tipo TPC-C han demostrado que el espacio utilizado ahora es un 40% menor en promedio. Ahora gastamos menos tiempo no solo en el mantenimiento de los \u00edndices de \u00e1rbol B (es decir, en las operaciones de escritura), sino tambi\u00e9n en la extracci\u00f3n de datos, ya que los \u00edndices se han reducido considerablemente.<\/p>\n

<\/p>\n

Las aplicaciones que actualizan activamente sus tablas, generalmente son aplicaciones OLTP (procesamiento de transacciones en tiempo real<\/a><\/noindex>), utilizar\u00e1n el disco de manera mucho m\u00e1s eficiente y procesar\u00e1n las consultas. Cuanto m\u00e1s espacio haya en el disco, m\u00e1s espacio tendr\u00e1 la base de datos para crecer sin necesidad de actualizar la infraestructura.<\/p>\n

<\/p>\n

Algunas estrategias de actualizaci\u00f3n requieren reconstruir los \u00edndices de \u00e1rbol B para aprovechar estas ventajas (por ejemplo, pg_upgrade<\/a><\/noindex> no reconstruir\u00e1 los \u00edndices autom\u00e1ticamente). En versiones anteriores de PostgreSQL, reconstruir grandes \u00edndices en tablas resultaba en un tiempo de inactividad significativo, dado que durante este tiempo no se pod\u00edan realizar cambios. Pero en PostgreSQL 12 hay otra caracter\u00edstica interesante: ahora se pueden reconstruir los \u00edndices de manera paralela con el comando REINDEX CONCURRENTLY<\/a><\/noindex>, para evitar completamente el tiempo de inactividad.<\/p>\n

<\/p>\n

En PostgreSQL 12 tambi\u00e9n hay otras mejoras en la infraestructura de indexaci\u00f3n. Otra cosa que no se qued\u00f3 sin magia es un diario de escritura anticipada<\/a><\/noindex>, tambi\u00e9n conocido como WAL (write-ahead log). El registro de escritura anticipada graba cada transacci\u00f3n en PostgreSQL en caso de fallos y replicaci\u00f3n. Las aplicaciones lo utilizan para la archivaci\u00f3n y recuperaci\u00f3n hasta un punto en el tiempo<\/a><\/noindex>. Por supuesto, el registro de escritura anticipada se escribe en el disco, lo que puede afectar el rendimiento.<\/p>\n

<\/p>\n

En PostgreSQL 12, se redujeron los costos de las entradas WAL generadas por los \u00edndices GiST, GIN y SP-GiST al construir un \u00edndice. Esto trae varias ventajas notables: las entradas WAL ocupan menos espacio en disco y los datos se reproducen m\u00e1s r\u00e1pido, por ejemplo, durante la recuperaci\u00f3n de fallos o la restauraci\u00f3n a un momento espec\u00edfico. Si utilizas estos \u00edndices en tus aplicaciones (como es el caso de las aplicaciones geoespaciales que utilizan mucho el \u00edndice GiST basado en PostGIS), esta es otra caracter\u00edstica que mejorar\u00e1 considerablemente el rendimiento sin ning\u00fan esfuerzo adicional de tu parte.<\/p>\n

<\/p>\n

Particionamiento: m\u00e1s, mejor, m\u00e1s r\u00e1pido<\/h3>\n

<\/p>\n

En PostgreSQL 10 se introdujo el particionamiento declarativo<\/a><\/noindex>. En PostgreSQL 11 se volvi\u00f3 mucho m\u00e1s f\u00e1cil de usar. En PostgreSQL 12 se puede cambiar la escala de las secciones.<\/p>\n

<\/p>\n

En PostgreSQL 12, el rendimiento del sistema de particionamiento ha mejorado considerablemente, especialmente si hay miles de secciones en la tabla. Por ejemplo, si una consulta solo afecta a unas pocas secciones en una tabla con miles de ellas, se ejecutar\u00e1 mucho m\u00e1s r\u00e1pido. La mejora del rendimiento no se limita a este tipo de consultas. Tambi\u00e9n notar\u00e1s que las operaciones INSERT en tablas con muchas secciones se han acelerado.<\/p>\n

<\/p>\n

La inserci\u00f3n de datos utilizando COPY<\/a><\/noindex> \u2014 por cierto, es una excelente manera de carga masiva de datos<\/a><\/noindex> y aqu\u00ed hay un ejemplo de la recepci\u00f3n de JSON<\/a><\/noindex> \u2014 en las tablas particionadas de PostgreSQL 12 tambi\u00e9n se ha vuelto m\u00e1s eficiente. Con COPY ya era r\u00e1pido, pero en PostgreSQL 12 es a\u00fan m\u00e1s veloz.<\/p>\n

<\/p>\n

Gracias a estas ventajas, en PostgreSQL se pueden almacenar conjuntos de datos de mayor tama\u00f1o, y su recuperaci\u00f3n se ha vuelto m\u00e1s sencilla. Y sin ning\u00fan esfuerzo de tu parte. Si tu aplicaci\u00f3n tiene muchas secciones, por ejemplo, si registra datos de series temporales, una simple actualizaci\u00f3n mejorar\u00e1 notablemente su rendimiento.<\/p>\n

<\/p>\n

Y aunque esta mejora no es realmente del tipo 'actualizamos y estamos contentos', en PostgreSQL 12 se pueden crear claves externas que apuntan a tablas particionadas, lo que hace que trabajar con particionamiento sea un placer.<\/p>\n

<\/p>\n

Las consultas WITH han mejorado mucho<\/h3>\n

<\/p>\n

Cuando se aplic\u00f3 un parche a las expresiones de tabla com\u00fan incorporadas<\/a><\/noindex> (tambi\u00e9n conocidas como CTE, o consultas WITH), ten\u00eda muchas ganas de escribir un art\u00edculo sobre c\u00f3mo los desarrolladores de aplicaciones con PostgreSQL . Esta es una de esas caracter\u00edsticas que acelerar\u00e1 la aplicaci\u00f3n. Si es que, por supuesto, utilizas CTE.<\/a><\/noindex>. Esta es una de esas caracter\u00edsticas que acelerar\u00e1 la aplicaci\u00f3n. Si es que, por supuesto, est\u00e1 utilizando CTE.<\/p>\n

<\/p>\n

A menudo noto que los principiantes en SQL tienden a usar CTE: si se escriben de una manera espec\u00edfica, sientes que est\u00e1s escribiendo un programa imperativo. Personalmente, me gustaba reescribir estas consultas para evitarlas. sin<\/em> CTE y mejorar el rendimiento. Ahora todo es diferente.<\/p>\n

<\/p>\n

PostgreSQL 12 permite incorporar un tipo espec\u00edfico de CTE sin efectos secundarios (SELECCIONAR<\/code>), que se utiliza solo una vez hacia el final de la consulta. Si llevara un registro de las consultas con CTE que reescrib\u00ed, la mayor\u00eda de ellas caer\u00edan en esta categor\u00eda. Esto ayuda a los desarrolladores a escribir c\u00f3digo entendible que ahora adem\u00e1s funciona r\u00e1pidamente.<\/p>\n

<\/p>\n

Adem\u00e1s, PostgreSQL 12 optimiza la ejecuci\u00f3n de SQL por s\u00ed mismo, no tendr\u00e1s que hacer nada. Y aunque ahora, probablemente, ya no tendr\u00e9 que optimizar esas consultas, es genial que PostgreSQL siga trabajando en la optimizaci\u00f3n de consultas.<\/p>\n

<\/p>\n

Just-in-Time (JIT) \u2014 ahora por defecto<\/h3>\n

<\/p>\n

En sistemas PostgreSQL 12 con soporte LLVM<\/a><\/noindex> La compilaci\u00f3n JIT est\u00e1 habilitada por defecto. Primero, obtienes soporte JIT<\/a><\/noindex> para algunas operaciones internas, y en segundo lugar, las consultas con expresiones (el ejemplo m\u00e1s simple es x + y) en las listas de selecci\u00f3n (las que tienes despu\u00e9s de SELECT), agregados, expresiones con cl\u00e1usulas WHERE y dem\u00e1s pueden utilizar JIT para mejorar el rendimiento.<\/p>\n

<\/p>\n

Dado que JIT est\u00e1 habilitado en PostgreSQL 12 por defecto, el rendimiento mejorar\u00e1 por s\u00ed mismo, pero recomiendo probar la aplicaci\u00f3n en PostgreSQL 11, donde JIT solo apareci\u00f3, para medir el rendimiento de las consultas y saber si se necesita ajustar algo.<\/p>\n

<\/p>\n

\u00bfY qu\u00e9 pasa con las dem\u00e1s nuevas funciones de PostgreSQL 12?<\/h3>\n

<\/p>\n

PostgreSQL 12 tiene un mont\u00f3n de nuevas funciones interesantes, desde la capacidad de explorar datos JSON utilizando las expresiones est\u00e1ndar de la ruta SQL\/JSON hasta la autenticaci\u00f3n multifactor con el par\u00e1metro clientcert=verify-full<\/code>, columnas generadas y mucho m\u00e1s. Merece una publicaci\u00f3n aparte.<\/p>\n

<\/p>\n

Al igual que PostgreSQL 10, PostgreSQL 12 aumentar\u00e1 el rendimiento general inmediatamente despu\u00e9s de la actualizaci\u00f3n. Por supuesto, puedes tener tu propio enfoque: prueba la aplicaci\u00f3n bajo condiciones similares en un sistema en producci\u00f3n antes de habilitar las mejoras, como hice yo con PostgreSQL 10. Incluso si PostgreSQL 12 ya es m\u00e1s estable de lo que pens\u00e9, no te des por vencido en realizar pruebas de calidad en las aplicaciones antes de lanzarlas en producci\u00f3n.<\/p>\n

Fuente: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

PostgreSQL 12, \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u044f\u044f \u0432\u0435\u0440\u0441\u0438\u044f \u00ab\u043b\u0443\u0447\u0448\u0435\u0439 \u0432 \u043c\u0438\u0440\u0435 \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u043e\u0439 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u0441 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u043c \u0438\u0441\u0445\u043e\u0434\u043d\u044b\u043c \u043a\u043e\u0434\u043e\u043c\u00bb, \u0432\u044b\u0445\u043e\u0434\u0438\u0442 \u0447\u0435\u0440\u0435\u0437 \u043f\u0430\u0440\u0443-\u0442\u0440\u043e\u0439\u043a\u0443 \u043d\u0435\u0434\u0435\u043b\u044c (\u0435\u0441\u043b\u0438 \u0432\u0441\u0435 \u043f\u043e\u0439\u0434\u0435\u0442 \u043f\u043e \u043f\u043b\u0430\u043d\u0443). \u042d\u0442\u043e \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u0435\u0442 \u043e\u0431\u044b\u0447\u043d\u043e\u043c\u0443 \u0440\u0430\u0441\u043f\u0438\u0441\u0430\u043d\u0438\u044e \u2014 \u043d\u043e\u0432\u0430\u044f \u0432\u0435\u0440\u0441\u0438\u044f \u0441 \u0443\u0439\u043c\u043e\u0439 \u043d\u043e\u0432\u044b\u0445 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0435\u0439 \u0432\u044b\u0445\u043e\u0434\u0438\u0442 \u0440\u0430\u0437 \u0432 \u0433\u043e\u0434, \u0438, \u0447\u0435\u0441\u0442\u043d\u043e \u0433\u043e\u0432\u043e\u0440\u044f, \u044d\u0442\u043e \u0432\u043f\u0435\u0447\u0430\u0442\u043b\u044f\u0435\u0442. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u044f \u0438 \u0441\u0442\u0430\u043b \u0430\u043a\u0442\u0438\u0432\u043d\u044b\u043c \u0447\u043b\u0435\u043d\u043e\u043c \u0441\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u0430 PostgreSQL. \u041f\u043e-\u043c\u043e\u0435\u043c\u0443, \u0432 \u043e\u0442\u043b\u0438\u0447\u0438\u0435 \u043e\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28500,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37975","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Actualizaci\u00f3n para los perezosos: c\u00f3mo PostgreSQL 12 mejora el rendimiento | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0410\u043f\u0433\u0440\u0435\u0439\u0434 \u0434\u043b\u044f \u043b\u0435\u043d\u0438\u0432\u044b\u0445: \u043a\u0430\u043a PostgreSQL 12 \u043f\u043e\u0432\u044b\u0448\u0430\u0435\u0442 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c | ProHoster","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:20:56+00:00","article:modified_time":"2019-10-31T19:20:56+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37975","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 19:59:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:17:22","updated":"2026-01-23 19:59:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/37975","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=37975"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/37975\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/28500"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=37975"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=37975"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=37975"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}