Re: AXLE Plans for 9.5 and 9.6

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: AXLE Plans for 9.5 and 9.6
Date: 2014-04-22 17:29:37
Message-ID: CAFj8pRAeqVhC9AYrRYi-yGurJhKbKziiHGn7mMn4uHaRo5sQvg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2014-04-22 19:02 GMT+02:00 Josh Berkus <josh(at)agliodbs(dot)com>:

> On 04/22/2014 06:39 AM, Andrew Dunstan wrote:
> > I agree, and indeed that was something like my first reaction to hearing
> > about this development - FDW seems like a very odd way to handle this.
> > But the notion of builtin columnar storage suggests to me that we really
> > need first to tackle how various storage engines might be incorporated
> > into Postgres. I know this has been a bugbear for many years, but maybe
> > now with serious proposals for alternative storage engines on the
> > horizon we can no longer afford to put off the evil day when we grapple
> > with it.
>
> Yes. *IF* PostgreSQL already supported alternate storage, then the
> Citus folks might have released their CStore as a storage plugin instead
> of an FDW. However, if they'd waited for pluggable storage, they'd
> still be waiting.
>

I am sceptical - what I know about OLAP column store databases - they need
a hardly different planner, so just engine or storage is not enough. Vector
Wise try to merge Ingres with Monet engine more than four years - and still
has some issues.

Our extensibility is probably major barrier against fast OLAP - I see a
most realistic way to support better partitioning and going in direction
higher parallelism and distribution - and maybe map/reduce support.

In GoodData we use successfully Postgres for BI projects to 20G with fast
response - and most painfulness are missing MERGE, missing fault tolerant
copy, IO expensive update of large tables with lot of indexes and missing
simple massive partitioning. On second hand - Postgres works perfectly on
thousands databases with thousands tables without errors with terrible
simple deploying in cloud environment.

Regards

Pavel

>
> --
> Josh Berkus
> PostgreSQL Experts Inc.
> http://pgexperts.com
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2014-04-22 17:54:01 Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD
Previous Message Joshua D. Drake 2014-04-22 17:06:20 Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD