Horton

Re: VLDB Features

Josh Berkus <josh@agliodbs.com>

View thread
From: Josh Berkus <josh@agliodbs.com>
To: pgsql-hackers@postgresql.org
Date: 2007-12-12T18:55:53Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. doc: Fix COPY ON_ERROR option syntax synopsis.

  2. Disallow specifying ON_ERROR option without value.

  3. Rename COPY option from SAVE_ERROR_TO to ON_ERROR

  4. Fix spelling in notice

  5. Add new COPY option SAVE_ERROR_TO

Markus,

> > Parallel Query
>
> Uh.. this only makes sense in a distributed database, no? I've thought
> about parallel querying on top of Postgres-R. Does it make sense
> implementing some form of parallel querying apart from the distribution
> or replication engine?

Sure.  Imagine you have a 5TB database on a machine with 8 cores and only one 
concurrent user.  You'd like to have 1 core doing I/O, and say 4-5 cores 
dividing the scan and join processing into 4-5 chunks.

I'd say implementing a separate I/O worker would be the first step towards 
this; if we could avoid doing I/O in the same process/thread where we're 
doing row parsing it would speed up large scans by 100%.  I know Oracle does 
this, and their large-table-I/O is 30-40% faster than ours despite having 
less efficient storage.

Maybe Greenplum or EnterpriseDB will contribute something.  ;-)

> > Windowing Functions
>
> Isn't Gavin Sherry working on this? Haven't read anything from him
> lately...

Me neither.  Swallowed by Greenplum and France.

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco