Let's see individual steps of the TPC-H benchmark, just as in the article about TPC-H benchmark with a traditional drive, i.e.

1. loading the data into tables
2. creating foreign keys and indexes
3. collecting statistics (ANALYZE with default_statistics_target=1000)
4. queries (22 queries defined by the TPC-H benchmark)

and the comparison of results is available here.

Loading the data

When loading the data the performance is about 1.5x of the traditional drive

and the dependency on block sizes is quite obvious - both for file system and database blocks holds "the larger the better." About the same is true for various modes of ext4 file system - ordered and writeback perform almost exactly the same (so I'll post just the ordered results)

but once we get to the journal mode, the performance drops noticeably

The XFS file system performs quite well, about the same as ext4-writeback.

Indexes and foreign keys

Even creating indexes and foreign keys is a bit faster - while with a traditional 7.2k drive the index creation took between 60 and 76 seconds (with 4kB file system blocks), with an SSD drive is just 46 to 59 seconds

On a traditional drive the foreign keys creation takes about 44 to 66 seconds, with an SSD drive it's about 24 to 66 seconds (i.e. the speedup is much more noticeable for large blocks).

Statistics

Almost everything stated in the previous section is true for collecting stats - with a traditional drive it takes about 70 to 80 seconds, on an SSD it's about 60 to 70 seconds.

Queries

Results of the main part of the benchmark, i.e. running queries are very balenced - when talking just about results with 4kB file system blocks, all file systems perform about the same. For example XFS performs like this

There's almost no dependency on file system block size and 32kB database blocks perform about 30% faster than 1kB blocks. The difference between 4kB and 32kB blocks is just about 6%.

For some of the file systems (ext4-journal, nilfs2) the file system block size actually does matter, and the small blocks perform significantly worse.

Note: If you're wondering why this picture is so different from the picture at the beginning (although both are labeled as m-time for XFS), it's due to the m-time definition. While the first image compares all the results (SSD and HDD at the same time), this picture is just for SSD, so the sets of queries are different. Details about the m-time definition are available in this article.

Conclusion

This section may be a bit misleading - I've realized that thanks to comment by Josh Berkus. Please, see the explanation at the end.

Performance in this TPC-H benchmark is influenced mostly by sequential operations, and that's not the main advantage of SSD drives compared to traditional drives, you can usually get about the same sequential performance for less money.

For example a 7.2k SATA drive provides about 80 MB/s of sequential writes, while the tested SSD can do that at about 130 MB/s. The difference is noticeable, but definitely not as significant as in case of random operations and is not worth the price difference, because for the tested 120GB SSD you'll pay 3x as much as for a 7.2k 1TB drive. By connecting 3 drives to a RAID 0 array (i.e. for about the same price as SSD drive) you'll get almost triple performance, i.e. about 2x the SSD performance.

No database workload is purely sequential or random, though - it's a combination of both. It's expected that the DSS/DWH workload is mostly sequential, although in case of operational data stores (used to support BI) there may be a significant portion of random operations. Not to mention that a join of tables may be evaluated as a nested loop with an index scan, a downright operation.

In any case, the benefit of SSD for DWH databases is significantly lower than with OLTP databases.

Notice: The primary purpose of this benchmark was to compare various file systems, not SSD vs. HDD, and this needs to be considered where interpreting the results. In case of pgbench results this is not a problem, because the queries are quite simple. But the TPC-H queries are quite complex, and if you change the block size (and random page cost), the query plans may differ significantly. But when you want to compare file system performance, you want to use exactly the same workload, otherwise it'd be apples to oranges. And that's exactly why I defined m-time and m-score (here), using only those queries that used exactly the same query plan in all cases.

There were only 6 such queries (of 22 defined by TPC-H), and by coincidence those are the 'mostly sequential' queries that don't do a lot of random I/O.

So the statement that "TPC-H benchmark is influenced mostly by sequential operations" is not true (some of the queries do a lot of random I/O). But the portion used for comparion is rather sequential, so the conclusion that SSDs are not good for sequential workloads is still valid. Which means you should really analyze your workload, and if it's not 'random enough' then SSDs won't give you much.

There's yet another catch - you have to consider indexes that would perform well with SSDs but with traditional HDDs they'd be inefficient (so you haven't created them yet). That means you can't just analyze the current workload, you have to review the indexes and maybe create some new ones ...