MAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matt Olson
Sent: Monday, May 09, 2005 9:10 PM
To: pgsql-performance@postgresql.org
Subject: [PERFORM] Prefetch
I wanted to get some opinions about row prefetching. AFAIK, there is no
prefetching done by PostgreSQL; all prefetching is delegate
I wanted to get some opinions about row prefetching. AFAIK, there is no
prefetching done by PostgreSQL; all prefetching is delegated to the operating
system.
The hardware (can't say enough good things about it):
Athlon 64, dual channel
4GB ram
240GB usable 4 disk raid5 (ATA133)
Fedora Core 3
Quoting Christopher Kings-Lynne <[EMAIL PROTECTED]>:
> > Another trick you can use with large data sets like this when you
> want
> > results
> > back in seconds is to have regularly updated tables that aggregate
> the data
> > along each column normally aggregated against the main data set.
>
>
Christopher Kings-Lynne wrote:
Another trick you can use with large data sets like this when you want
results
back in seconds is to have regularly updated tables that aggregate the
data
along each column normally aggregated against the main data set.
Maybe some bright person will prove me wrong
On Wed, 2005-05-11 at 12:53 +0800, Christopher Kings-Lynne wrote:
> > Another trick you can use with large data sets like this when you want
> > results
> > back in seconds is to have regularly updated tables that aggregate the data
> > along each column normally aggregated against the main data s
Another trick you can use with large data sets like this when you want
results
back in seconds is to have regularly updated tables that aggregate the data
along each column normally aggregated against the main data set.
Maybe some bright person will prove me wrong by posting some working
informat
Matt Olson wrote:
Other databases like Oracle and DB2 implement some sort of row prefetch. Has
there been serious consideration of implementing something like a prefetch
subsystem? Does anyone have any opinions as to why this would be a bad idea
for postgres?
Postges is great for a multiuser envi
kSQL. )
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Browne
Sent: Tuesday, May 10, 2005 4:14 PM
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Prefetch - OffTopic
[EMAIL PROTECTED] ("Mohan, Ross") writes:
> for time-serie
[EMAIL PROTECTED] ("Mohan, Ross") writes:
> for time-series and "insane fast", nothing beats kdB, I believe
>
> www.kx.com
... Which is well and fine if you're prepared to require that all of
the staff that interact with data are skilled APL hackers. Skilled
enough that they're all ready to leap
2:54 PM
To: Greg Stark
Cc: [EMAIL PROTECTED]; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Prefetch
Greg Stark <[EMAIL PROTECTED]> writes:
> Actually forcing things to use indexes is the wrong direction to go if
> you're trying to process lots of data and want to strea
Greg Stark <[EMAIL PROTECTED]> writes:
> Actually forcing things to use indexes is the wrong direction to go if you're
> trying to process lots of data and want to stream it off disk as rapidly as
> possible. I would think about whether you can structure your data such that
> you can use sequential
My postgres binaries and WAL are on a separate disk from the raid array. The
table I'm doing the selects from is probably about 4GB in size and 18-20
million records. No concurrent or dependent inserts or deletes are going on.
Tom's point and your points about optimizing the application are we
Matt Olson <[EMAIL PROTECTED]> writes:
> I've done other things that make sense, like using indexes, playing with the
> planner constants and turning up the postgres cache buffers.
>
> Even playing with extream hdparm read-ahead numbers (i.e. 64738) yields no
> apparent difference in database pe
> I've done other things that make sense, like using indexes, playing with the
> planner constants and turning up the postgres cache buffers.
After you load the new days data try running CLUSTER on the structure
using a key of (stockID, date) -- probably your primary key.
This should significantl
Matt Olson <[EMAIL PROTECTED]> writes:
> Other databases like Oracle and DB2 implement some sort of row prefetch. Has
> there been serious consideration of implementing something like a prefetch
> subsystem?
No.
> Does anyone have any opinions as to why this would be a bad idea for
> postgres?
I wanted to get some opinions about row prefetching. AFAIK, there is no
prefetching done by PostgreSQL; all prefetching is delegated to the operating
system.
The hardware (can't say enough good things about it):
Athlon 64, dual channel
4GB ram
240GB usable 4 disk raid5 (ATA133)
Fedora Core 3
Pos
16 matches
Mail list logo
