Re: The need for clustered indexes to boost TPC-V performance

On Thu, Jul 5, 2012 at 12:13 PM, Reza Taheri <rtaheri(at)vmware(dot)com> wrote:

> Hi Robert,
> Yes, the same concept. Oracle's IOT feature is used often with TPC
> benchmarks.
>
>
Reza, it would be very helpful if you were to provide the list with a lot
more information about your current software and hardware configuration
before coming to the conclusion that the only possible way forward is with
a significant architectural change to the db engine itself. Not only is it
not at all clear that you are extracting maximum performance from your
current hardware and software, but I doubt anyone is particularly
interested in doing a bunch of development purely to game a benchmark.
There has been significant discussion of the necessity and viability of
the feature you are requesting in the past, so you should probably start
where those discussions left off rather than starting the discussion all
over again from the beginning. Of course, if vmware were to sponsor
development of the feature in question, it probably wouldn't require nearly
as much buy-in from the wider community.

Getting back to the current performance issues - I have little doubt that
the MS SQL benchmark was set up and run by people who were intimately
familiar with MS SQL performance tuning. You stated in your earlier email
that your team doesn't have significant postgresql-specific experience, so
it isn't necessarily surprising that your first attempt at tuning didn't
get the results that you are looking for. You stated that you have 14 SSDs
and 90 spinning drives, but you don't specify how they are combined and how
the database is laid out on top of them. There is no mention of how much
memory is available to the system. We don't know how you've configured
postgresql's memory allocation or how your config weights the relative
costs of index lookups, sequential scans, etc. The guidelines for this
mailing list include instructions for what information should be provided
when asking about performance improvements.
http://archives.postgresql.org/pgsql-performance/ Let's start by
ascertaining how your benchmark results can be improved without engaging in
a significant development effort on the db engine itself.