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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
