On Tue, Jan 25, 2011 at 5:32 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Wed, Jan 19, 2011 at 12:07 PM, Bruce Momjian br...@momjian.us wrote:
? ? ? ?http://developer.postgresql.org/pgdocs/postgres/non-durability.html
This sentence looks to me like it should be removed,
Jeff Janes wrote:
On Tue, Jan 25, 2011 at 5:32 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Wed, Jan 19, 2011 at 12:07 PM, Bruce Momjian br...@momjian.us wrote:
? ? ?
?http://developer.postgresql.org/pgdocs/postgres/non-durability.html
This sentence looks to me
Robert Haas wrote:
On Wed, Jan 19, 2011 at 12:07 PM, Bruce Momjian br...@momjian.us wrote:
Chris Browne wrote:
gentosa...@gmail.com (A B) writes:
If you just wanted PostgreSQL to go as fast as possible WITHOUT any
care for your data (you accept 100% dataloss and datacorruption if any
On Wed, Jan 19, 2011 at 12:07 PM, Bruce Momjian br...@momjian.us wrote:
Chris Browne wrote:
gentosa...@gmail.com (A B) writes:
If you just wanted PostgreSQL to go as fast as possible WITHOUT any
care for your data (you accept 100% dataloss and datacorruption if any
error should occur),
Chris Browne wrote:
gentosa...@gmail.com (A B) writes:
If you just wanted PostgreSQL to go as fast as possible WITHOUT any
care for your data (you accept 100% dataloss and datacorruption if any
error should occur), what settings should you use then?
Use /dev/null. It is web scale, and
2011/1/19 Bruce Momjian br...@momjian.us
FYI, we do have a documentation section about how to configure Postgres
for improved performance if you don't care about durability:
http://developer.postgresql.org/pgdocs/postgres/non-durability.html
A sometime ago I wrote in my blog [1]
On Fri, Nov 5, 2010 at 8:12 AM, Jon Nelson jnelson+pg...@jamponi.net wrote:
On Fri, Nov 5, 2010 at 7:08 AM, Guillaume Cottenceau g...@mnc.ch wrote:
Marti Raudsepp marti 'at' juffo.org writes:
On Fri, Nov 5, 2010 at 13:32, A B gentosa...@gmail.com wrote:
I was just thinking about the case
On 11/15/2010 9:06 AM, Robert Haas wrote:
In 9.1, I'm hopeful that we'll have unlogged tables, which will even
better than turning these parameters off, and for which I just posted
a patch to -hackers. Instead of generating WAL and writing WAL to the
OS and then NOT trying to make sure it hits
On Mon, Nov 15, 2010 at 2:27 PM, Andy Colson a...@squeakycode.net wrote:
On 11/15/2010 9:06 AM, Robert Haas wrote:
In 9.1, I'm hopeful that we'll have unlogged tables, which will even
better than turning these parameters off, and for which I just posted
a patch to -hackers. Instead of
How about either:-
a) Size the pool so all your data fits into it.
b) Use a RAM-based filesystem (ie: a memory disk or SSD) for the
data storage [memory disk will be faster] with a Smaller pool
- Your seed data should be a copy of the datastore on disk filesystem;
at startup time copy the
Lello, Nick nick.le...@rentrakmail.com writes:
A bigger gain can probably be had if you have a tightly controlled
suite of queries that will be run against the database and you can
spend the time to tune each to ensure it performs no sequential scans
(ie: Every query uses index lookups).
Use a replicated setup?
On Nov 8, 2010 4:21 PM, Lello, Nick nick.le...@rentrakmail.com wrote:
How about either:-
a) Size the pool so all your data fits into it.
b) Use a RAM-based filesystem (ie: a memory disk or SSD) for the
data storage [memory disk will be faster] with a Smaller pool
-
On 11/05/2010 07:32 PM, A B wrote:
The server will just boot, load data, run, hopefully not crash but if
it would, just start over with load and run.
Have you looked at VoltDB? It's designed for fast in-memory use.
--
Craig Ringer
--
Sent via pgsql-performance mailing list
On 5 November 2010 10:59, A B gentosa...@gmail.com wrote:
Hi there.
If you just wanted PostgreSQL to go as fast as possible WITHOUT any
care for your data (you accept 100% dataloss and datacorruption if any
error should occur), what settings should you use then?
Turn off fsync and
On 5 November 2010 11:14, Thom Brown t...@linux.com wrote:
On 5 November 2010 10:59, A B gentosa...@gmail.com wrote:
Hi there.
If you just wanted PostgreSQL to go as fast as possible WITHOUT any
care for your data (you accept 100% dataloss and datacorruption if any
error should occur),
A B gentosaker 'at' gmail.com writes:
Hi there.
If you just wanted PostgreSQL to go as fast as possible WITHOUT any
care for your data (you accept 100% dataloss and datacorruption if any
error should occur), what settings should you use then?
Don't use PostgreSQL, just drop your data, you
On 5 November 2010 11:59, A B gentosa...@gmail.com wrote:
Hi there.
If you just wanted PostgreSQL to go as fast as possible WITHOUT any
care for your data (you accept 100% dataloss and datacorruption if any
error should occur), what settings should you use then?
I'm just curious, what do
Turn off fsync and full_page_writes (i.e. running with scissors).
Also depends on what you mean by as fast as possible. Fast at doing
what? Bulk inserts, selecting from massive tables?
I guess some tuning has to be done to make it work well with the
particular workload (in this case most
On 05/11/10 18:59, A B wrote:
Hi there.
If you just wanted PostgreSQL to go as fast as possible WITHOUT any
care for your data (you accept 100% dataloss and datacorruption if any
error should occur), what settings should you use then?
Others have suggested appropriate parameters (running
If you just wanted PostgreSQL to go as fast as possible WITHOUT any
care for your data (you accept 100% dataloss and datacorruption if any
error should occur), what settings should you use then?
I'm just curious, what do you need that for?
regards
Szymon
I was just thinking about the
If you just wanted PostgreSQL to go as fast as possible WITHOUT any
care for your data (you accept 100% dataloss and datacorruption if any
error should occur), what settings should you use then?
Others have suggested appropriate parameters (running with scissors).
I'd like to add something
On Fri, Nov 5, 2010 at 13:32, A B gentosa...@gmail.com wrote:
I was just thinking about the case where I will have almost 100%
selects, but still needs something better than a plain key-value
storage so I can do some sql queries.
The server will just boot, load data, run, hopefully not crash
On 5 November 2010 11:36, Marti Raudsepp ma...@juffo.org wrote:
On Fri, Nov 5, 2010 at 13:32, A B gentosa...@gmail.com wrote:
I was just thinking about the case where I will have almost 100%
selects, but still needs something better than a plain key-value
storage so I can do some sql
On Fri, Nov 5, 2010 at 13:11, Guillaume Cottenceau g...@mnc.ch wrote:
Don't use PostgreSQL, just drop your data, you will end up with
the same results and be even faster than any use of PostgreSQL.
If anyone needs data, then just say you had data corruption, and
that since 100% dataloss is
Marti Raudsepp marti 'at' juffo.org writes:
On Fri, Nov 5, 2010 at 13:11, Guillaume Cottenceau g...@mnc.ch wrote:
Don't use PostgreSQL, just drop your data, you will end up with
the same results and be even faster than any use of PostgreSQL.
If anyone needs data, then just say you had data
Marti Raudsepp marti 'at' juffo.org writes:
On Fri, Nov 5, 2010 at 13:32, A B gentosa...@gmail.com wrote:
I was just thinking about the case where I will have almost 100%
selects, but still needs something better than a plain key-value
storage so I can do some sql queries.
The server will
On Fri, Nov 5, 2010 at 7:08 AM, Guillaume Cottenceau g...@mnc.ch wrote:
Marti Raudsepp marti 'at' juffo.org writes:
On Fri, Nov 5, 2010 at 13:32, A B gentosa...@gmail.com wrote:
I was just thinking about the case where I will have almost 100%
selects, but still needs something better than a
On Fri, 2010-11-05 at 11:59 +0100, A B wrote:
If you just wanted PostgreSQL to go as fast as possible WITHOUT any
care for your data (you accept 100% dataloss and datacorruption if any
error should occur), what settings should you use then?
You can initdb to ramdisk, if you have enough RAM.
gentosa...@gmail.com (A B) writes:
If you just wanted PostgreSQL to go as fast as possible WITHOUT any
care for your data (you accept 100% dataloss and datacorruption if any
error should occur), what settings should you use then?
Use /dev/null. It is web scale, and there are good tutorials.
Devrim GÜNDÜZ wrote:
On Fri, 2010-11-05 at 11:59 +0100, A B wrote:
If you just wanted PostgreSQL to go as fast as possible WITHOUT any
care for your data (you accept 100% dataloss and datacorruption if any
error should occur), what settings should you use then?
You can initdb to
30 matches
Mail list logo
