使用Postgres汇总列值和按月分组日期

Question

I've got a table in my Postgres DB that looks something like this:

date          duration
2018-05-10      10
2018-05-12      15
2018-06-01      10
2018-06-02      20
2019-01-01      5
2019-01-02      15
2019-04-01      10

And I wish to sum the values for each month and group them by year, month and, month number into something like this:

year    month    month_number   monthly_sum
2018    May         5              25
2018    June        6              30
2019    Jan         1              20
2019    Apr         4              10

And ended up with a query that looks like this:

SELECT 
  to_char(date_trunc('month', date), 'YYYY') AS year,
  to_char(date_trunc('month', date), 'Mon') AS month,
  to_char(date_trunc('month', date), 'MM') AS month_number,
  sum(duration) AS monthly_sum
FROM timesheet 
GROUP BY year, month, month_number

And it works just fine, my question is: is this query considered bad? Will it affect performance if I have like.. 100k rows? I heard using to_char is inferior to date_trunc, which is what I tried to avoid here, I just wrapped the date_trunc in a to_char. Also, having three values in a GROUP BY clause, does it affect anything?

Answer 1

using functions and grouping using them accordingly may degrade performance. It is preferable to have Calendar table with proper indexes for this purpose, so that you won't need to deal with such issues on every table.

Check This and this (Calendar Table)

Answer 2

The query is not bad, but you can simplify it.

SELECT to_char(date_trunc('month', date), 'YYYY') AS year,
       to_char(date_trunc('month', date), 'Mon') AS month,
       to_char(date_trunc('month', date), 'MM') AS month_number,
       sum(duration) AS monthly_sum
FROM timesheet 
GROUP BY date_trunc('month', date);

From a performance perspective, shorter GROUP BY keys would have a small impact on performance, but that is not something I would worry about.

Answer 3

Since your query does not have any filtering condition, it's always reading all the rows of the table: this is the major impact in performance. Had you had filtering conditions, you could be better of having the right indexes.

Having said that, the way you are extracting years and months could be marginally improved as other answers here show, but that will have little impact in the performance of the query.

In sum, in the absence of filtering conditions your query is close to optimal.