Kevin Grittner wrote:
With either platters or BBU cache,
the data is persisted on fsync; why do you see a risk with one but
not the other
Forgot to address this part. The troublesome sequence if you don't have
a BBU is:
1) WAL data is written to the OS cache
2) PG calls fsync
3) Data is tra
Greg Smith writes:
> At this point, you now have a torn 8K page, with 1/2 old and 1/2 new
> data.
Right.
> Without a full page write in the WAL, is it always possible to
> restore its original state now? In theory, I think you do. Since the
> delta in the WAL should be overwriting all of th
Kevin Grittner wrote:
I assume that we send a full
8K to the OS cache, and the file system writes disk sectors
according to its own algorithm. With either platters or BBU cache,
the data is persisted on fsync; why do you see a risk with one but
not the other
I'd like a 10 minute argument pleas
On Oct 21, 2010, at 11:13 AM, Jesper Krogh wrote:
> On 2010-10-21 06:47, Scott Carey wrote:
> > On a wimpy disk, I/O bound for
> sure. But my disks go 1000MB/sec.
>
> > No query can go fast enough for them. The best I've gotten is
>
> > 800MB/sec, on a wide row (average 800 bytes). Most tab
On Thursday 21 October 2010 21:42:06 Kevin Grittner wrote:
> Bruce Momjian wrote:
> > I assume we send a full 8k to the controller, and a failure during
> > that write is not registered as a write.
>
> On what do you base that assumption? I assume that we send a full
> 8K to the OS cache, and th
> -Original Message-
> From: AI Rumman [mailto:rumman...@gmail.com]
> Sent: Thursday, October 21, 2010 1:25 AM
> To: pgsql-performance@postgresql.org
> Subject: Index scan is not working, why??
>
> I don't know why seq scan is running on the following query
> where the same query is g
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > I assume we send a full 8k to the controller, and a failure during
> > that write is not registered as a write.
>
> On what do you base that assumption? I assume that we send a full
> 8K to the OS cache, and the file system writes disk sector
Bruce Momjian wrote:
> I assume we send a full 8k to the controller, and a failure during
> that write is not registered as a write.
On what do you base that assumption? I assume that we send a full
8K to the OS cache, and the file system writes disk sectors
according to its own algorithm. W
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > If the write fails to the controller, the page is not flushed and
> > PG does not continue. If the write fails, the fsync never
> > happens, and hence PG stops.
>
> PG stops? This case at issue is when the OS crashes or the plug is
> pulled
Bruce Momjian wrote:
> If the write fails to the controller, the page is not flushed and
> PG does not continue. If the write fails, the fsync never
> happens, and hence PG stops.
PG stops? This case at issue is when the OS crashes or the plug is
pulled in the middle of writing a page. I do
Kevin Grittner wrote:
> Greg Smith wrote:
> > Kevin Grittner wrote:
>
> >> So you're confident that an 8kB write to the controller will not
> >> be done as a series of smaller atomic writes by the OS file
> >> system?
> >
> > Sure, that happens. But if the BBU has gotten an fsync call after
>
Hello,
Does anyone have any experience with running postgreSQL on Blue Arc's
network storage products? In particular, we are interested in the the
Titan and Mercury series:
http://www.bluearc.com/data-storage-products/titan-3000-network-storage-system.shtml
http://www.bluearc.com/data-storage
Kevin Grittner wrote:
> wrote:
>
> > -- None of that is anything for amateurs to play with.
> >
> > Not jam a stick in anybody's eye, but shouldn't database pros not
> > be amateurs?
>
> While many PostgreSQL installations are managed by professional
> DBAs, or programmers or consultants with
Greg Smith wrote:
> Kevin Grittner wrote:
>> So you're confident that an 8kB write to the controller will not
>> be done as a series of smaller atomic writes by the OS file
>> system?
>
> Sure, that happens. But if the BBU has gotten an fsync call after
> the 8K write, it shouldn't return suc
On 2010-10-21 06:47, Scott Carey wrote:
On a wimpy disk, I/O bound for sure. But my disks go 1000MB/sec.
No query can go fast enough for them. The best I've gotten is
800MB/sec, on a wide row (average 800 bytes). Most tables go
300MB/sec or so. And with 72GB of RAM, many scans are in-mem
Kevin Grittner wrote:
Bruce Momjian wrote:
full_page_writes is designed to guard against a partial write to a
device. I don't think the raid cache can be partially written to
So you're confident that an 8kB write to the controller will not be
done as a series of smaller atomic wri
Bruce Momjian wrote:
> full_page_writes is designed to guard against a partial write to a
> device. I don't think the raid cache can be partially written to
So you're confident that an 8kB write to the controller will not be
done as a series of smaller atomic writes by the OS file system?
-
Bruce Momjian wrote:
With a BBU you can turn off full_page_writes, which should decrease the
WAL traffic.
However, I don't see this mentioned in our documentation. Should I add
it?
What I would like to do is beef up the documentation with some concrete
examples of how to figure out if you
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > With a BBU you can turn off full_page_writes
>
> My understanding is that that is not without risk. What happens if
> the WAL is written, there is a commit, but the data page has not yet
> been written to the controller? Don't we still have
Bruce Momjian wrote:
> With a BBU you can turn off full_page_writes
My understanding is that that is not without risk. What happens if
the WAL is written, there is a commit, but the data page has not yet
been written to the controller? Don't we still have a torn page?
-Kevin
--
Sent via
Scott Marlowe wrote:
> On Wed, Oct 20, 2010 at 8:25 PM, Joshua D. Drake
> wrote:
> > On Wed, 2010-10-20 at 22:13 -0400, Bruce Momjian wrote:
> >> Ben Chobot wrote:
> >> > On Oct 7, 2010, at 4:38 PM, Steve Crawford wrote:
> >> >
> >> > > I'm weighing options for a new server. In addition to Postgr
Gael Le Mignot writes:
> Thu, 21 Oct 2010 10:55:48 -0400, you wrote:
>>> I think this may be caused by GIN's habit of queuing index insertions
>>> until it's accumulated a reasonable-size batch:
>>> http://www.postgresql.org/docs/9.0/static/gin-implementation.html#GIN-FAST-UPDATE
> So a big work
On 10/20/2010 09:45 PM, Scott Marlowe wrote:
On Wed, Oct 20, 2010 at 8:25 PM, Joshua D. Drake wrote:
On Wed, 2010-10-20 at 22:13 -0400, Bruce Momjian wrote:
Ben Chobot wrote:
On Oct 7, 2010, at 4:38 PM, Steve Crawford wrote:
I'm weighing options for a new server.
Gael Le Mignot wrote:
Hello,
We are using PostgreSQL for storing data and full-text search indexes
for the webiste of a daily newspaper. We are very happy overall with the
results, but we have one "weird" behaviour that we would like to solve.
The problem is when we index objects into the
Greg Smith wrote:
> Now that some of my recent writing has gone from NDA protected to public
> sample, I've added a new page to the PostgreSQL wiki that provides a
> good starting set of resources to learn about an ever popular topic
> here, how write cache problems can lead to database corrupti
Hello Tom!
Thu, 21 Oct 2010 10:55:48 -0400, you wrote:
> Gael Le Mignot writes:
>> The problem is when we index objects into the full-text search part of
>> the database (which a DELETE and then an INSERT into a specific table),
>> the INSERT sometimes take a long time (from 10s to 20s
Gael Le Mignot wrote:
The delay is the delay of the "sync" part of
the checkpoints :
2010-10-21 16:39:15 CEST LOG: checkpoint complete: wrote 365 buffers
(11.9%); 0 transaction log file(s) added, 0 removed, 3 recycled;
write=0.403 s, sync=21.312 s, total=21.829 s
Maybe there is something I m
2010/10/21 Leonardo Francalanci :
>> 2010-10-21 16:39:15 CEST LOG: checkpoint complete: wrote 365 buffers
>> (11.9%); 0 transaction log file(s) added, 0 removed, 3 recycled;
>> write=0.403 s, sync=21.312 s, total=21.829 s
>
>
> I'm no expert, but isn't 21s to sync 365 buffers a big amount of ti
Brad Nicholson wrote:
I think a warning turning fsync off, the dangers of async_commit, and
the potential problems with disabling full_page_writes might be worth
mentioning on this page, unless you want to leave that buried in the
attached references.
Good idea to highlight that. What I just
> 2010-10-21 16:39:15 CEST LOG: checkpoint complete: wrote 365 buffers
> (11.9%); 0 transaction log file(s) added, 0 removed, 3 recycled;
> write=0.403 s, sync=21.312 s, total=21.829 s
I'm no expert, but isn't 21s to sync 365 buffers a big amount of time?
--
Sent via pgsql-performance m
> > does it use a BBU?)
Sorry, this was supposed to read "do you have cache on the controller", of
course a battery can't change the performance... but you got it anyway...
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
h
Hello Leonardo!
Thu, 21 Oct 2010 14:15:40 +0100 (BST), you wrote:
>> We are using PostgreSQL for storing data and full-text search indexes
>> for the webiste of a daily newspaper. We are very happy overall with the
>> results, but we have one "weird" behaviour that we would like to solv
Gael Le Mignot writes:
> The problem is when we index objects into the full-text search part of
> the database (which a DELETE and then an INSERT into a specific table),
> the INSERT sometimes take a long time (from 10s to 20s), but the same
> insert (and many other similar ones) are fast (b
On 10-10-21 10:08 AM, Greg Smith wrote:
Now that some of my recent writing has gone from NDA protected to
public sample, I've added a new page to the PostgreSQL wiki that
provides a good starting set of resources to learn about an ever
popular topic here, how write cache problems can lead to da
Now that some of my recent writing has gone from NDA protected to public
sample, I've added a new page to the PostgreSQL wiki that provides a
good starting set of resources to learn about an ever popular topic
here, how write cache problems can lead to database corruption:
http://wiki.postgres
AI Rumman wrote:
I don't know why seq scan is running on the following query where the
same query is giving index scan on other servers:
explain analyze
select *
from act
where act.acttype in ( 'Meeting','Call','Task');
QUERY PLAN
-
> We are using PostgreSQL for storing data and full-text search indexes
> for the webiste of a daily newspaper. We are very happy overall with the
> results, but we have one "weird" behaviour that we would like to solve.
I think there's a lot of missing info worth knowing:
1) checkpoints
Hi,
There are a lot of details missing about your system:
http://wiki.postgresql.org/wiki/SlowQueryQuestions
Cheers,
Ken
On Thu, Oct 21, 2010 at 02:25:44PM +0200, Gael Le Mignot wrote:
>
> Hello,
>
> We are using PostgreSQL for storing data and full-text search indexes
> for the webiste of
Hello,
We are using PostgreSQL for storing data and full-text search indexes
for the webiste of a daily newspaper. We are very happy overall with the
results, but we have one "weird" behaviour that we would like to solve.
The problem is when we index objects into the full-text search part o
On Thu, Oct 21, 2010 at 1:51 AM, Samuel Gendler
wrote:
> please provide non-default config options on this host plus the same from a
> host which is using an index scan, please. Also, postgresql version, OS,
> and all of the other stuff that is asked for in this
> document: http://wiki.postgresql
please provide non-default config options on this host plus the same from a
host which is using an index scan, please. Also, postgresql version, OS,
and all of the other stuff that is asked for in this document:
http://wiki.postgresql.org/wiki/SlowQueryQuestions. It is impossible to say
why the q
41 matches
Mail list logo
