Thread: Any good olap benchmarks?

Any good olap benchmarks?

From
Vladimir Rusinov
Date:
Hi!

I'm searching for any good OLAP-like benchmark: I need some benchmark
with complex selects run on 10-30G dataset, something like this:
http://www.percona.com/docs/wiki/benchmark:wikistat:start, but this is
only a draft and would only be released for mysql.

I've found DBT-3 benchmark, but it lacks documentation and I have no
idea how to run in over network (I need server and client to be on
different hosts).

--
Vladimir Rusinov
Google Profile: http://www.google.com/profiles/vladimir.rusinov


Re: Any good olap benchmarks?

From
Greg Smith
Date:
Vladimir Rusinov wrote:
> I'm searching for any good OLAP-like benchmark: I need some benchmark
> with complex selects run on 10-30G dataset, something like this:
> http://www.percona.com/docs/wiki/benchmark:wikistat:start, but this is
> only a draft and would only be released for mysql.
>

I already intended to convert and run Vadim's Wikipedia statistics
benchmark when I get to it; as we're busy getting the next PostgreSQL
release out the door right now I just haven't gotten to it yet.  I
expect we can get that added into their mix on the same hardware once
I'm done.

I've linked to everything I'm aware of at
http://wiki.postgresql.org/wiki/Category:Benchmarking and the TPC-H page
has probably the most relevant information for OLAP.  PostgreSQL doesn't
do particularly well on OLAP benchmarks yet due to how queries are
limited by a single processor, making it hard to get excited about
publishing the results.

Greenplum ran some interesting tests of their own software against
PostgreSQL at http://community.greenplum.com/showthread.php?t=113 you
might find interesting.  That includes a fairly easy to use TPC-H like
test kit program, and by showing where they did much better is suggest
the areas that community Postgres struggles relative to software that
handles parallel query across multiple cores/servers.

--
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us


Re: Any good olap benchmarks?

From
lst_hoe02@kwsoft.de
Date:
Zitat von Greg Smith <greg@2ndquadrant.com>:

> I've linked to everything I'm aware of at
> http://wiki.postgresql.org/wiki/Category:Benchmarking and the TPC-H
> page has probably the most relevant information for OLAP.
> PostgreSQL doesn't do particularly well on OLAP benchmarks yet due
> to how queries are limited by a single processor, making it hard to
> get excited about publishing the results.
>
> Greenplum ran some interesting tests of their own software against
> PostgreSQL at http://community.greenplum.com/showthread.php?t=113
> you might find interesting.  That includes a fairly easy to use
> TPC-H like test kit program, and by showing where they did much
> better is suggest the areas that community Postgres struggles
> relative to software that handles parallel query across multiple
> cores/servers.

I maybe wrong but this looks like "partitioning" PostgreSQL to me???




PgPool-II - does it do re-connect?

From
Evan Rempel
Date:
I am looking ahead to when postgresql 9.x is non-beta and how
we can best make use of the "virtually synchronous" replication.

At our site, we have a load balancer appliance that works very well
in that it can direct a connection to one of a number
of back ends. When one back end goes away, connections will
be created to the remaining back ends. I think that this will
work well for the postgres failover, however, the database connection
will drop (I don't see how existing connections can be failed to the
hot-standby postgres server) and need to be established again.
Since I can not rely on the applications to perform the reconnect,
I was wondering if anyone knows if PgPool-II can accomplish this for
me. If it can, then the applications will not be aware that they have
been reconnected, they will just be aware that any outstanding transaction
failed.

Can anyone comment on this functionality of PgPool-II or on this
approach to failover in general?

Evan Rempel.