pganalyze
pganalyze
  • 157
  • 141 758
Webinar Recording: How to Compare Postgres Plans & Tune Slow Queries with pganalyze
Are slow queries hurting your application's performance? Whether they creep in over time or strike all of a sudden, slow queries can significantly impact user experience and system efficiency.
Optimizing queries in PostgreSQL is particularly challenging due to how the query planner works-it doesn't always choose the most optimal execution plan. Factors like join order, index scans, misleading cost estimations, and the manual burden of analysis can all contribute to suboptimal query performance.
In this practical webinar, we show you how to use pganalyze, a product for monitoring and optimizing Postgres performance, to do slow query debugging using techniques for various real-world scenarios. We’ll also mention the underlying Postgres mechanisms that support pganalyze’s functionality.
Find the presentation deck and additional resources: pganalyze.com/webinars/thank-you-compare-postgres-plans-tune-queries
มุมมอง: 463

วีดีโอ

PGConf NYC 2024: How to tune a slow Postgres query with pganalyze
มุมมอง 6353 หลายเดือนก่อน
In this session we walk through best practices of optimizing a slow query in Postgres, and how we can have a better mental model for how Postgres plans out a query, be it join order, index usage, or planner costing - and getting a sense for knowing when it goes wrong. We'll then discuss different ways of finding tuning opportunities for a given query, and how to benchmark them. These approaches...
Postgres Planner Quirks: Incremental Sort, and when it goes wrong
มุมมอง 3803 หลายเดือนก่อน
*Find the article on our blog here:* pganalyze.com/blog/5mins-postgres-incremental-sort In E120 of "5mins of Postgres" we return to our Postgres planner quirks series to talk about Incremental Sort, and when it goes wrong. Incremental Sort can often speed up query plans when you have an existing sort order; however, there can be edge cases where the planner chooses a sub-optimal plan. *Learn mo...
Webinar Recording: Hands on Postgres 17: What's New & How It Impacts Performance
มุมมอง 2.2K3 หลายเดือนก่อน
Find the presentation slide deck and all other shared material below! On September 26, 2024, we hosted our webinar on the release of Postgres 17, it's updates & how they're set to impact performance. You can find the presentation slides and references here: pganalyze.com/webinars/thank-you-hands-on-postgres17-whats-new *Additional Q&A* Are you going to do a 5mins of Postgres on the B-Tree IN/AN...
Webinar recording: Optimizing slow queries with EXPLAIN to fix bad query plans
มุมมอง 2.1K6 หลายเดือนก่อน
Find the presentation slide deck and all other shared material below! On June 18th, 2024, we hosted our webinar on how to use EXPLAIN effectively to optimize slow queries in Postgres, and how to identify bad query plans, due to issues such as Postgres planner row mis-estimates. We were glad to see over 500 attendees and were happy to answer over 70 questions in our Q&A session and the post-webi...
The surprising logic of the Postgres work_mem setting, and how to tune it
มุมมอง 1.1K6 หลายเดือนก่อน
*Find the article on our blog here:* pganalyze.com/blog/5mins-postgres-work-mem-tuning In E119 of "5mins of Postgres" we discuss tuning the Postgres work_mem setting for your workload, and why it can be quite confusing to interpret the meaning of work_mem correctly for a given query. We also discuss the impact of hash_mem_multiplier, and why it's default changed from 1.0 to 2.0 in Postgres 15. ...
Waiting for Postgres 17: Better Query Plans for Materialized CTE Scans
มุมมอง 5487 หลายเดือนก่อน
*Find the article on our blog here:* pganalyze.com/blog/5mins-postgres-17-materialized-cte-scans In E118 of "5mins of Postgres" we discuss two changes in the upcoming Postgres 17 release that improve query plans for queries that involve CTEs. This can improve query plans where you would see an explicit CTE scan, due to use of the MATERIALIZED keyword, or because Postgres wasn't able to pull up ...
Postgres Planner Quirks: JOIN Equivalence Classes and IN/ANY filters
มุมมอง 4407 หลายเดือนก่อน
*Find the article on our blog here:* pganalyze.com/blog/5mins-postgres-planner-join-equivalence-class-in-any-filters In E117 of "5mins of Postgres" we continue our series on Postgres planner quirks. In this episode we discuss JOIN column equivalence and when there are issues with IN/ANY filters not being considered as part of the equivalence class in Postgres. *Learn more about pganalyze:* pgan...
What's (not) in Postgres 17 beta1, and how to test it
มุมมอง 5257 หลายเดือนก่อน
*Find the article on our blog here:* pganalyze.com/blog/5mins-postgres-17-beta1 In E116 of "5mins of Postgres" we discuss the Postgres 17 beta1 release that came out earlier this week, some highlights of the release, some changes that unfortunately got reverted since the feature freeze, and how to help the community during the beta testing process. *Learn more about pganalyze:* pganalyze.com pg...
Postgres Planner Quirks: How to fix bad JSONB selectivity estimates
มุมมอง 4317 หลายเดือนก่อน
*Find the article on our blog here:* pganalyze.com/blog/5mins-postgres-planner-jsonb-selectivity In E115 of "5mins of Postgres" we discuss a common challenge when using equality and contains operators for querying JSONB columns, and why the Postgres planner will often get the estimates wrong for such queries, causing bad query plans. *Learn more about pganalyze:* pganalyze.com pganalyze.com/new...
Postgres CVE-2024-4317 and how to fix the system views
มุมมอง 5217 หลายเดือนก่อน
*Find the article on our blog here:* pganalyze.com/blog/5mins-postgres-cve-2024-4317-system-views In E114 of "5mins of Postgres" we discuss the updated Postgres minor releases that were just released this week. And specifically, we're going to talk about the security issue that was fixed in this release. Now I'll tell you first off, that this security issue, CVE-2024-4317 is a fairly minor one,...
Postgres Planner Quirks: The impact of ORDER BY + LIMIT on index usage
มุมมอง 8108 หลายเดือนก่อน
Postgres Planner Quirks: The impact of ORDER BY LIMIT on index usage
Waiting for Postgres 17: Streaming I/O for sequential scans & ANALYZE
มุมมอง 6678 หลายเดือนก่อน
Waiting for Postgres 17: Streaming I/O for sequential scans & ANALYZE
Waiting for Postgres 17: Faster B-Tree Index Scans for IN(...) lists and ANY =
มุมมอง 7498 หลายเดือนก่อน
Waiting for Postgres 17: Faster B-Tree Index Scans for IN(...) lists and ANY =
Waiting for Postgres 17: Benchmarking with pg_buffercache_evict
มุมมอง 4138 หลายเดือนก่อน
Waiting for Postgres 17: Benchmarking with pg_buffercache_evict
Waiting for Postgres 17: Faster VACUUM with Adaptive Radix Trees
มุมมอง 5619 หลายเดือนก่อน
Waiting for Postgres 17: Faster VACUUM with Adaptive Radix Trees
Waiting for Postgres 17: Improved EXPLAIN for SubPlan nodes
มุมมอง 3539 หลายเดือนก่อน
Waiting for Postgres 17: Improved EXPLAIN for SubPlan nodes
Waiting for Postgres 17: The new built-in C.UTF-8 locale
มุมมอง 5189 หลายเดือนก่อน
Waiting for Postgres 17: The new built-in C.UTF-8 locale
How Figma built DBProxy for sharding Postgres
มุมมอง 9449 หลายเดือนก่อน
How Figma built DBProxy for sharding Postgres
Tuning random_page_cost and how index correlation affects query plans
มุมมอง 47810 หลายเดือนก่อน
Tuning random_page_cost and how index correlation affects query plans
Waiting for Postgres 17: Configurable SLRU cache sizes for increased performance
มุมมอง 56210 หลายเดือนก่อน
Waiting for Postgres 17: Configurable SLRU cache sizes for increased performance
Speeding up partial COUNT(*) in Postgres by using LIMIT in a subquery
มุมมอง 57610 หลายเดือนก่อน
Speeding up partial COUNT(*) in Postgres by using LIMIT in a subquery
Out of range planner statistics and "get_actual_variable_range" in Postgres
มุมมอง 21410 หลายเดือนก่อน
Out of range planner statistics and "get_actual_variable_range" in Postgres
Faster query plans with Postgres 16: Incremental Sorts, Anti-JOINs and more
มุมมอง 66711 หลายเดือนก่อน
Faster query plans with Postgres 16: Incremental Sorts, Anti-JOINs and more
Reducing table size with optimal column ordering and array-based storage
มุมมอง 76811 หลายเดือนก่อน
Reducing table size with optimal column ordering and array-based storage
Finding the root cause of locking problems in Postgres
มุมมอง 1.1K11 หลายเดือนก่อน
Finding the root cause of locking problems in Postgres
How to partition Postgres tables by timestamp based UUIDs
มุมมอง 1.1K11 หลายเดือนก่อน
How to partition Postgres tables by timestamp based UUIDs
The different trade-offs of Distributed Postgres architectures
มุมมอง 54411 หลายเดือนก่อน
The different trade-offs of Distributed Postgres architectures
Waiting for Postgres 17: Incremental base backups
มุมมอง 1.2Kปีที่แล้ว
Waiting for Postgres 17: Incremental base backups
Zero downtime Postgres upgrades and how to logically replicate very large tables
มุมมอง 1.6Kปีที่แล้ว
Zero downtime Postgres upgrades and how to logically replicate very large tables

ความคิดเห็น

  • @rebelwwg1wga431
    @rebelwwg1wga431 19 วันที่ผ่านมา

    Do you think postgresql/postgis and probably citus cluster will be ok for service like zillow or i should choose scylladb? Thanks

  • @juozasnorkus3926
    @juozasnorkus3926 23 วันที่ผ่านมา

    Great video!

  • @rows5486
    @rows5486 หลายเดือนก่อน

    thx for links to source ❤

  • @FirstLast-zs6dq
    @FirstLast-zs6dq หลายเดือนก่อน

    Thanks man, caught deadlock, split transactions, sped up query.

  • @atulsinha9025
    @atulsinha9025 2 หลายเดือนก่อน

    Does enabling auto_explain make a negative impact on the postgres engine? For example, any increase in log generation adversely affecting the CPU and I/O for application queries?

    • @pganalyze6516
      @pganalyze6516 หลายเดือนก่อน

      With the right settings, it's low overhead, generally less than 1% impact on performance. Here are the settings we recommend: pganalyze.com/docs/explain/setup/self_managed/03_review_settings

    • @prakashv.k792
      @prakashv.k792 หลายเดือนก่อน

      It increases the IO and CPU as well.. enable it for a while for profiling and disable immediately

  • @RafaelAkmetdinov
    @RafaelAkmetdinov 2 หลายเดือนก่อน

    Thank you for video. In some places your sound is a little bit broken

    • @pganalyze6516
      @pganalyze6516 2 หลายเดือนก่อน

      Yes, unfortunately we recorded this from the laptop mic directly which made the audio low quality in some portions. We'll have a webinar soon that dives into this topic and goes into more detail on the product features, that will have a proper studio microphone in use.

    • @pganalyze6516
      @pganalyze6516 หลายเดือนก่อน

      This webinar is now available :) pganalyze.com/webinars/how-to-compare-postgres-plans-and-tune-slow-queries

  • @docteurklein
    @docteurklein 2 หลายเดือนก่อน

    love it!

  • @Aaron-p8h5l
    @Aaron-p8h5l 2 หลายเดือนก่อน

    great talk!

  • @jaimeduncan6167
    @jaimeduncan6167 2 หลายเดือนก่อน

    Thanks !!!

  • @dhavald4359
    @dhavald4359 3 หลายเดือนก่อน

    guessable keys should not be a threat. regardless of guessable or not, the backend should have authorization logic that prevents unauthorized data access.

  • @mraaroncruz
    @mraaroncruz 3 หลายเดือนก่อน

    Thanks Lukas. I've only really thought about cardinality when using a time series DB. Great info

  • @BizAutomation4U
    @BizAutomation4U 3 หลายเดือนก่อน

    What a great overview about a topic anyone with an App running PostgreSQL will want to knkow about. Thank you ! I think our ERP is now around 750 tables, on Webforms, and thousands of stored procs.

  • @DavidSchmitt
    @DavidSchmitt 3 หลายเดือนก่อน

    Chonky! Makes me excited for the upgrade

  • @DavidTuron1
    @DavidTuron1 3 หลายเดือนก่อน

    Thanks, nice preview of new changes and features:)

  • @glokta1
    @glokta1 4 หลายเดือนก่อน

    Just discovered your channel and I've been binge-watching all your videos haha. Great stuff

  • @paniconamoto06
    @paniconamoto06 4 หลายเดือนก่อน

    How do I also record the user who made the change? pgaudit

  • @ПорфирийКаравайкин
    @ПорфирийКаравайкин 4 หลายเดือนก่อน

    Thank you for this lesson! I've set random_page_cost wich dropped seq scan on one of our heavy query. This led to significant drop in CPU utilisation. I wonder if you can add somehow this suggestion into pganalyze

  • @BboyHotshot
    @BboyHotshot 5 หลายเดือนก่อน

    Check Citus which powers Azure Cosmos DB.

  • @TheHeartOfTheEvil
    @TheHeartOfTheEvil 5 หลายเดือนก่อน

    Oh wow the WHEN NOT MATCHED BY SOURCE was exactly what I needed lol, thank you to whoever implemented it!

  • @ГеоргийТрубецкой-л2щ
    @ГеоргийТрубецкой-л2щ 5 หลายเดือนก่อน

    Thanks. You channel name is "pganalyze". Does it mean the pganalyze utility, right? But it is not free. But, at least, you make the good videos, so the commercial company made something good.

  • @JamesBData
    @JamesBData 5 หลายเดือนก่อน

    This is top-notch Postgres content. Thanks for presenting it!

  • @IIIxwaveIII
    @IIIxwaveIII 5 หลายเดือนก่อน

    great info, is still inside the 17 release?

    • @jaimeduncan6167
      @jaimeduncan6167 5 หลายเดือนก่อน

      yes. Crossing fingers no big error is found from here to the release.

  • @mirceacadariu341
    @mirceacadariu341 6 หลายเดือนก่อน

    Thanks, great content as always

  • @GT-zg5qz
    @GT-zg5qz 6 หลายเดือนก่อน

    Hello. I guess 25% was recommended as starting point, because it is better when default value. And, of course here may not be enough memory for another processes. As a result, the 45-50% is a finish.

  • @ayoubarahmat
    @ayoubarahmat 6 หลายเดือนก่อน

    thanks for sharing

    • @pganalyze6516
      @pganalyze6516 6 หลายเดือนก่อน

      You're very welcome! Thanks for your interest!

  • @nurxg
    @nurxg 7 หลายเดือนก่อน

    What is CTE?

    • @pganalyze6516
      @pganalyze6516 7 หลายเดือนก่อน

      CTE = Common Table Expression, or "WITH [name] AS ( SELECT ...) SELECT" in a query. See www.postgresql.org/docs/current/queries-with.html

  • @iamharisai
    @iamharisai 7 หลายเดือนก่อน

    Damn, that's a great explanation in 5 mins. You rocked it Lukas

  • @DavidSchmitt
    @DavidSchmitt 7 หลายเดือนก่อน

    That's a booby trap if I've ever seen one. Luckily the fix seems pretty easy!

  • @yazdan6504
    @yazdan6504 7 หลายเดือนก่อน

    What are the demerits of setting random_page_cost as low as 1.1 If there are some queries on my db , that get benefited from lower the random page cost, is there any other queries that would get hampered due to this?

  • @jirehla-ab1671
    @jirehla-ab1671 7 หลายเดือนก่อน

    @pganalyze, can the same prepared transaction be utilized across multiple connections in postgres?

  • @jocketf3083
    @jocketf3083 7 หลายเดือนก่อน

    Interesting! Thank You!

  • @jirehla-ab1671
    @jirehla-ab1671 7 หลายเดือนก่อน

    Would prepared transactions be no benefit in oltp wirkloads where Assuming that each client will only be executing single block of transactions as opposed to executing multiple blocks of transactions?

  • @szuliq
    @szuliq 8 หลายเดือนก่อน

    You did great thing there. Thanks for great content, as always!

  • @awksedgreep
    @awksedgreep 8 หลายเดือนก่อน

    Currently spending the next 6 weekends purging data from a large complex 3nf database with UUID FKs between all of the tables. On an extremely large instance(192G Ram, 48 vCPUs) I'm getting <31 deletes/sec with all the ugly UUID FK lookups.

    • @LukasFittl
      @LukasFittl 8 หลายเดือนก่อน

      That sounds like a lot of work! I assume you have an index covering the foreign key lookup? (since you commented on an episode where we talk about indexing UUIDs, I assume you're running into the exact problem with indexes on UUIDs being bloated?)

    • @awksedgreep
      @awksedgreep 8 หลายเดือนก่อน

      @@LukasFittl Correct, and all those complex index lookups for all the referencing tables are slowing down deletes, even though we've handled(rolled off and purged) all the referencing rows. All referencing tables have been fully vacuumed as well after cleanup so they should be fresh. Still super slow.

    • @LukasFittl
      @LukasFittl 8 หลายเดือนก่อน

      @@awksedgreep Makes sense. If you haven't done so already, it might be worth trying a REINDEX CONCURRENTLY on the affected indexes that support the foreign key. Even after a regular vacuum, there would be lots of inefficient index structure left behind that a reindex can fix up.

  • @filipebraganca2558
    @filipebraganca2558 8 หลายเดือนก่อน

    Never heard about that +0 solution. Genious!!!! Thanks for sharing it.

  • @andatki
    @andatki 8 หลายเดือนก่อน

    Woo hoo. Nice job to everyone involved on this as well, including you Lukas for helping raise awareness of this and connect everything together. In Active Record Rails apps, I’ve seen problematic IN clauses with a large amount of values, showing up in PGSS. My feeling is this is going to help a lot when this becomes available.

    • @LukasFittl
      @LukasFittl 8 หลายเดือนก่อน

      Yeah, I'm excited about what this will bring for the typical Rails app - these overly long IN lists are very much a Rails pattern that should see a noticeable performance benefit here with 17.

  • @jeralvx
    @jeralvx 8 หลายเดือนก่อน

    very effective 5 minutes -- thanks for the great vid!

  • @raphaelsantanaguitar
    @raphaelsantanaguitar 8 หลายเดือนก่อน

    I am very glad to have found this channel! Got some performance concerns when working with a correlated subquery and this was very enlightening! Thanks

    • @LukasFittl
      @LukasFittl 8 หลายเดือนก่อน

      Happy to hear you found it useful!

  • @jocketf3083
    @jocketf3083 8 หลายเดือนก่อน

    Awesome!

  • @DavidSchmitt
    @DavidSchmitt 9 หลายเดือนก่อน

    Nice boost. Vacuum can never be fast enough ❤

  • @MrWulfSolter
    @MrWulfSolter 9 หลายเดือนก่อน

    Thanks for doing these Lukas! I really appreciate your summaries of the features/functionality in commit logs

    • @LukasFittl
      @LukasFittl 9 หลายเดือนก่อน

      Thanks Wulf! Its an excellent excuse to actually test the new functionality :)

  • @MrMetalWarlock
    @MrMetalWarlock 9 หลายเดือนก่อน

    This is a gem!

  • @AkshatJain11
    @AkshatJain11 9 หลายเดือนก่อน

    Great video, very well explained!

  • @qiweishen5524
    @qiweishen5524 9 หลายเดือนก่อน

    Very interesting! Curious does the unpartitioned table has an index on the partition by column? If not, is the join by index better than partition-wise join

  • @byterelay
    @byterelay 10 หลายเดือนก่อน

    Thanks, Lukas! Very interesting overview, I was not aware of many details. BTW there will be a talk on this topic by Dilip at PGConf this year. Looking forward to it.

  • @diegonayalazo
    @diegonayalazo 10 หลายเดือนก่อน

    Thanks Lucas ❤

  • @andatki
    @andatki 10 หลายเดือนก่อน

    Nice examples Lukas showing the SQL to set up ranges using the new functions.

    • @LukasFittl
      @LukasFittl 10 หลายเดือนก่อน

      Thanks Andy!

  • @andatki
    @andatki 11 หลายเดือนก่อน

    Thanks Lukas! For this kind of excellent, but densely filled blog post, on high value planner optimizations with example queries that benefit, I appreciate having this overview of the items to start to digest them. It's easier to slot the quick audio into my day, then I can go back into the nitty gritty details of the post and try the examples out. Thanks to David, Melanie, and all the contributors for these improvements!

    • @LukasFittl
      @LukasFittl 11 หลายเดือนก่อน

      Thanks Andy, happy to hear you found it useful!

  • @smyrnian_
    @smyrnian_ 11 หลายเดือนก่อน

    Congratulations on 100th episode Lukas!