Greg Smith wrote:
In practice, the "ordered"
mode (the default for ext3) seems sufficient to prevent database
corruption. There is a substantial performance hit to running in full
journal mode like you're doing;
where do you see which mode I am running in? I havent specified any
modes in
On Thu, 4 Sep 2008, Thomas Finneid wrote:
I am unsure if I need a journal in the fs or if the db covers that problem.
There are some theoretical cases where the guarantees of ext3 seems a
little weak unless you've turned the full journal on even in a database
context (we just had a long thre
What about filesystem properties?
on linux I am using:
ext3(with journal) and auto,rw,async,noatime,nodiratime
on disks for data and journal
I am unsure if I need a journal in the fs or if the db covers that
problem. With regards to that, do I then need to set some linux setting
to forc
On Mon, 1 Sep 2008, Scott Carey wrote:
Thanks for the info on the patch to support it -- however the versions
posted there are rather old...
Over here, we're using an extremely old patched version of the JDBC
driver. That's the patch I sent to some mailing list a couple of years
ago. It works
On Tue, 2 Sep 2008, Thomas Finneid wrote:
You should try setting this to open_sync , that can be considerably faster
for some write-heavy situations. Make sure to test that throughly though,
there are occasional reports of issues with that setting under Linux
The production machine is Solari
Greg Smith wrote:
On Mon, 1 Sep 2008, Thomas Finneid wrote:
Thanks for all the info on the disk controller, I will have to look
through all that now :)
I note that nobody has talked about your postgresql.conf yet. I assume
you've turned autovacuum off because you're not ever deleting thing
On Mon, 1 Sep 2008, Thomas Finneid wrote:
It does have a sata raid controller, but not have the battery pack, because
its a develmachine and not a production machine, I thought it was not needed.
But if you are saying the battery pack enables a cache which enables faster
disk writes I will con
On Mon, Sep 1, 2008 at 12:41 PM, Gregory Stark <[EMAIL PROTECTED]>wrote:
> "Scott Carey" <[EMAIL PROTECTED]> writes:
>
> > On Raid Controllers and Dev machines:
> >
> > For a dev machine the battery backup is NOT needed.
> >
> > Battery back up makes a _production_ system faster: In production, d
On Mon, Sep 1, 2008 at 2:42 PM, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> dialog box saying this is a bad idea. Now, if it would take you a day
> of downtime to get a dev database back in place and running after a
> power loss, then the bbu may be worth the $200 or so.
I just wanted to comment t
On Mon, Sep 1, 2008 at 2:32 PM, Thomas Finneid
<[EMAIL PROTECTED]> wrote:
>
> Scott Carey wrote:
>>
>> For a development box, just enable write-back caching regardless of the
>> battery back up situation. As long as its not your only copy of
>
> Will have a look at it, the data is not important an
>
>
>
> On the performance impact of using COPY instead of INSERT : out of
>> curiosity, were you comparing COPY against raw row-by-row inserts (slow) or
>> JDBC batch inserts (faster) or multi-row inserts: INSERT into X (a,b,c)
>> values (1,2,3) , (4,5,6) , (7,8,9 ) , (10,11,12) ?
>>
>
> I
Scott Carey wrote:
For a development box, just enable write-back caching regardless of the
battery back up situation. As long as its not your only copy of
Will have a look at it, the data is not important and can be reproduced
any time on any machine. The controller I have is a Areca ARC-12
"Scott Carey" <[EMAIL PROTECTED]> writes:
> On Raid Controllers and Dev machines:
>
> For a dev machine the battery backup is NOT needed.
>
> Battery back up makes a _production_ system faster: In production, data
> integrity is everything, and write-back caching is dangerous without a
> battery
On Raid Controllers and Dev machines:
For a dev machine the battery backup is NOT needed.
Battery back up makes a _production_ system faster: In production, data
integrity is everything, and write-back caching is dangerous without a
battery back up.
So:
Without BBU: Write-through cache = data
On Mon, Sep 1, 2008 at 5:29 AM, Thomas Finneid
<[EMAIL PROTECTED]> wrote:
> It does have a sata raid controller, but not have the battery pack, because
> its a develmachine and not a production machine, I thought it was not
> needed. But if you are saying the battery pack enables a cache which ena
Craig Ringer wrote:
Just on a side note, your system is pretty strangely heavy on CPU
compared to its RAM and disk configuration. Unless your workload in Pg
is computationally intensive or you have something else hosted on the
same machine, those CPUs will probably sit mostly idle.
Its a devel
Scott Carey wrote:
Are you even getting COPY to work with JDBC? As far as I am aware, COPY
doesn't work with JDBC at the moment:
I used a patched jdbc driver, provided by someone on the list, dont have
the reference at hand. It works perfectly and its about 5 times faster,
for my job, than
Are you even getting COPY to work with JDBC? As far as I am aware, COPY
doesn't work with JDBC at the moment:
http://jdbc.postgresql.org/todo.html Listed in the todo page, under "PG
Extensions" is "Add support for COPY." I tried to use it with JDBC a
while ago and gave up after a couple limit
Thomas Finneid wrote:
> Hi
>
> I am working on a table which stores up to 125K rows per second and I
> find that the inserts are a little bit slow. The insert is in reality a
> COPY of a chunk of rows, up to 125K. A COPY og 25K rows, without an
> index, is fast enough, about 150ms. With the index,
Scott Carey wrote:
You may want to investigate pg_bulkload.
http://pgbulkload.projects.postgresql.org/
One major enhancement over COPY is that it does an index merge, rather
than modify the index one row at a time.
This is a command line tool, right? I need a jdbc driver tool, is that
pos
You may want to investigate pg_bulkload.
http://pgbulkload.projects.postgresql.org/
One major enhancement over COPY is that it does an index merge, rather than
modify the index one row at a time.
http://pgfoundry.org/docman/view.php/1000261/456/20060709_pg_bulkload.pdf
On Sun, Aug 31, 2008 at
21 matches
Mail list logo
