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
On Thu, Oct 21, 2010 at 1:51 AM, Samuel Gendler
sgend...@ideasculptor.com 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:
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 of
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 a
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
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
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:
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
Gael Le Mignot g...@pilotsystems.net 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
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:
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
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
2010/10/21 Leonardo Francalanci m_li...@yahoo.it:
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
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
Hello Tom!
Thu, 21 Oct 2010 10:55:48 -0400, you wrote:
Gael Le Mignot g...@pilotsystems.net 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
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 corruption:
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
On 10/20/2010 09:45 PM, Scott Marlowe wrote:
On Wed, Oct 20, 2010 at 8:25 PM, Joshua D. Drakej...@commandprompt.com 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
Gael Le Mignot g...@pilotsystems.net 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
Scott Marlowe wrote:
On Wed, Oct 20, 2010 at 8:25 PM, Joshua D. Drake j...@commandprompt.com
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
Bruce Momjian br...@momjian.us 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 Grittner wrote:
Bruce Momjian br...@momjian.us 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
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
Bruce Momjian br...@momjian.us 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
Kevin Grittner wrote:
Bruce Momjian br...@momjian.us 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
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
Greg Smith g...@2ndquadrant.com 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
Kevin Grittner wrote:
gnuo...@rcn.com 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
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
Kevin Grittner wrote:
Greg Smith g...@2ndquadrant.com 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
Bruce Momjian br...@momjian.us 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
Kevin Grittner wrote:
Bruce Momjian br...@momjian.us 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
-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 giving
On Thursday 21 October 2010 21:42:06 Kevin Grittner wrote:
Bruce Momjian br...@momjian.us 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
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 tables go
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
Greg Smith g...@2ndquadrant.com 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
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
38 matches
Mail list logo
