Jeff Janes wrote:
> On Tue, Jan 25, 2011 at 5:32 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Wed, Jan 19, 2011 at 12:07 PM, Bruce Momjian wrote:
>
> >> > ? ? ?
> >> > ?http://developer.postgresql.org/pgdocs/postgres/non-durability.html
> >>
> >> This sentence looks to me like it sho
On Tue, Jan 25, 2011 at 5:32 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Wed, Jan 19, 2011 at 12:07 PM, Bruce Momjian wrote:
>> > ? ? ? ?http://developer.postgresql.org/pgdocs/postgres/non-durability.html
>>
>> This sentence looks to me like it should be removed, or perhaps clarified:
>>
Robert Haas wrote:
> On Wed, Jan 19, 2011 at 12:07 PM, Bruce Momjian 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 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), what set
2011/1/19 Bruce Momjian
>
> 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] (sorry but av
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 scal
On Mon, Nov 15, 2010 at 2:27 PM, Andy Colson 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 generating WAL and
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 t
On Fri, Nov 5, 2010 at 8:12 AM, Jon Nelson wrote:
> On Fri, Nov 5, 2010 at 7:08 AM, Guillaume Cottenceau wrote:
>> Marti Raudsepp writes:
>>
>>> On Fri, Nov 5, 2010 at 13:32, A B wrote:
I was just thinking about the case where I will have almost 100%
selects, but still needs something
Use a replicated setup?
On Nov 8, 2010 4:21 PM, "Lello, Nick" 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
- Your seed data should be
"Lello, Nick" 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).
Given a fixed pool of que
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 sto
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 (pgsql-performanc
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 ramdi
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.
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 R
On Fri, Nov 5, 2010 at 7:08 AM, Guillaume Cottenceau wrote:
> Marti Raudsepp writes:
>
>> On Fri, Nov 5, 2010 at 13:32, A B 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 som
Marti Raudsepp writes:
> On Fri, Nov 5, 2010 at 13:32, A B 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, hopefu
Marti Raudsepp writes:
> On Fri, Nov 5, 2010 at 13:11, Guillaume Cottenceau 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 sin
On Fri, Nov 5, 2010 at 13:11, Guillaume Cottenceau 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 accepted, t
On 5 November 2010 11:36, Marti Raudsepp wrote:
> On Fri, Nov 5, 2010 at 13:32, A B 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
On Fri, Nov 5, 2010 at 13:32, A B 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 but if
> it would
>> 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
>> 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
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 ("runni
> 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 5 November 2010 11: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?
>
>
I'm just curious, what do you need that
A B 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 will end up with
the s
On 5 November 2010 11:14, Thom Brown wrote:
> On 5 November 2010 10: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 u
On 5 November 2010 10: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?
>
>
Turn off fsync and full_page_writes (i.e.
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?
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make chang
31 matches
Mail list logo
