On Mon, Jun 14, 2010 at 15:59, Tom Lane wrote:
> Magnus Hagander writes:
>> On Sun, Jun 13, 2010 at 21:19, David Jarvis wrote:
>>> I prefer to_timestamp and to_date over the more verbose construct_timestamp.
>
>> Yeah, I agree with that.
>
> Those names are already taken. It will cause confusio
On 6/15/10 10:37 AM, Chris Browne wrote:
> swamp...@noao.edu (Steve Wampler) writes:
>> Or does losing WAL files mandate a new initdb?
>
> Losing WAL would mandate initdb, so I'd think this all fits into the
> set of stuff worth putting onto ramfs/tmpfs. Certainly it'll all be
> significant to th
On Tue, Jun 15, 2010 at 12:37 PM, Chris Browne wrote:
> swamp...@noao.edu (Steve Wampler) writes:
>> Or does losing WAL files mandate a new initdb?
>
> Losing WAL would mandate initdb, so I'd think this all fits into the
> set of stuff worth putting onto ramfs/tmpfs. Certainly it'll all be
> sign
Greg Smith wrote:
Eliot Gable wrote:
Just curious if this would apply to PostgreSQL:
http://queue.acm.org/detail.cfm?id=1814327
It's hard to take this seriously at all when it's so ignorant of
actual research in this area. Take a look at
http://www.cc.gatech.edu/~bader/COURSES/UNM/ece637-Fa
swamp...@noao.edu (Steve Wampler) writes:
> Or does losing WAL files mandate a new initdb?
Losing WAL would mandate initdb, so I'd think this all fits into the
set of stuff worth putting onto ramfs/tmpfs. Certainly it'll all be
significant to the performance focus.
--
select 'cbbrowne' || '@' ||
On Jun 15, 8:47 am, Chris Browne wrote:
> "jgard...@jonathangardner.net" writes:
> > My question is how can I configure the database to run as quickly as
> > possible if I don't care about data consistency or durability? That
> > is, the data is updated so often and it can be reproduced fairly
>
[oops, didn't hit "reply to list" first time, resending...]
On 6/15/10 9:02 AM, Steve Wampler wrote:
Chris Browne wrote:
"jgard...@jonathangardner.net" writes:
My question is how can I configure the database to run as quickly as
possible if I don't care about data consistency or durability? T
Chris Browne wrote:
"jgard...@jonathangardner.net" writes:
My question is how can I configure the database to run as quickly as
possible if I don't care about data consistency or durability? That
is, the data is updated so often and it can be reproduced fairly
rapidly so that if there is a serv
"jgard...@jonathangardner.net" writes:
> My question is how can I configure the database to run as quickly as
> possible if I don't care about data consistency or durability? That
> is, the data is updated so often and it can be reproduced fairly
> rapidly so that if there is a server crash or ran
On Mon, 14 Jun 2010, Eliot Gable wrote:
Just curious if this would apply to PostgreSQL:
http://queue.acm.org/detail.cfm?id=1814327
Absolutely, and I said in
http://archives.postgresql.org/pgsql-performance/2010-03/msg00272.php
but applied to the Postgres B-tree indexes instead of heaps. It's a
10 matches
Mail list logo
