Timeline for Querying large tables in postgresql
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 12, 2022 at 10:56 | vote | accept | Bruno Giehl | ||
| Sep 9, 2022 at 10:52 | comment | added | Frank Heikens | Could you share the results from EXPLAIN(ANALYZE, VERBOSE, BUFFERS) for this query? Without it, nobody knows where most of the time is spent and how to optimise the issue | |
| Sep 8, 2022 at 14:55 | answer | added | Bruno Giehl | timeline score: 2 | |
| Sep 8, 2022 at 14:11 | comment | added | Bruno Giehl | Yep, both columns on both tables. | |
| Sep 8, 2022 at 13:49 | comment | added | J.D. |
Well really, my question should've been, do you have an index on (year, t1_cod) for both tables?
|
|
| Sep 8, 2022 at 13:44 | comment | added | Bruno Giehl | Using the filter before the join was a try to reduce rows to make the join faster, and worked pretty fine, but still got a problem setting up the filtered year | |
| Sep 8, 2022 at 13:37 | comment | added | Bruno Giehl | Yep. In fact, join that tables with the t1_cod was even slower because of the number of rows. In that case, postgres performs a sequencial scan, even if the column is indexed. | |
| Sep 8, 2022 at 13:33 | comment | added | J.D. |
Do you have an index on t1.t1_cod and index on t2.t1_cod?
|
|
| S Sep 8, 2022 at 13:20 | review | First questions | |||
| Sep 8, 2022 at 22:15 | |||||
| S Sep 8, 2022 at 13:20 | history | asked | Bruno Giehl | CC BY-SA 4.0 |