what's the table and index look like? how do you test? Is it HOT update?
For update table and index ,you can read this:
http://www.dbrnd.com/2016/12/postgresql-increase-the-speed-of-update-query-using-hot-update-heap-only-tuple-mvcc-fill-factor-vacuum-fragmentation/
2017年6月13日 1:06 PM，"Potukanuma
On 11/25/15 5:38 AM, Tomas Vondra wrote:
But be generally wary of turning of fpw's if you use replication.
Not having them often turns a asynchronously batched write workload
into one containing a lot of synchronous, single threaded, reads.
Even with SSDs that can very quickly lead to not being a
Cc: PostgreSQL
Subject: Re: [GENERAL] full_page_writes on SSD?
Hi,
I investigate bit about SSD and how it works and need to be aligned .
And I conclude that in the ideal world we need a general --ebs=xxx switch in
various linux tools to ensure alignment. Or make calculation by had..
On the mar
of data may have
some benefits not with the speed but in lower wear-out of the entire ssd
disk..
-- Původní zpráva --
Od: Marcin Mańk
Komu: PostgreSQL
Datum: 24. 11. 2015 20:07:30
Předmět: [GENERAL] full_page_writes on SSD?
"
I saw this: http://blog.pgaddic
On 11/24/2015 08:40 PM, John R Pierce wrote:
On 11/24/2015 10:48 AM, Marcin Mańk wrote:
I saw this:
http://blog.pgaddict.com/posts/postgresql-on-ssd-4kb-or-8kB-pages
It made me wonder: if SSDs have 4kB/8kB sectors, and we'd make the
Postgres page size equal to the SSD page size, do we still nee
On 11/24/2015 08:14 PM, Andres Freund wrote:
On 2015-11-24 13:09:58 -0600, Kevin Grittner wrote:
On Tue, Nov 24, 2015 at 12:48 PM, Marcin Mańk wrote:
if SSDs have 4kB/8kB sectors, and we'd make the Postgres page
size equal to the SSD page size, do we still need
full_page_writes?
If an OS wr
On 11/24/2015 10:48 AM, Marcin Mańk wrote:
I saw this:
http://blog.pgaddict.com/posts/postgresql-on-ssd-4kb-or-8kB-pages
It made me wonder: if SSDs have 4kB/8kB sectors, and we'd make the
Postgres page size equal to the SSD page size, do we still need
full_page_writes?
an SSD's actual writ
On 2015-11-24 13:09:58 -0600, Kevin Grittner wrote:
> On Tue, Nov 24, 2015 at 12:48 PM, Marcin Mańk wrote:
>
> > if SSDs have 4kB/8kB sectors, and we'd make the Postgres page
> > size equal to the SSD page size, do we still need full_page_writes?
>
> If an OS write of the PostgreSQL page size ha
On Tue, Nov 24, 2015 at 12:48 PM, Marcin Mańk wrote:
> if SSDs have 4kB/8kB sectors, and we'd make the Postgres page
> size equal to the SSD page size, do we still need full_page_writes?
If an OS write of the PostgreSQL page size has no chance of being
partially persisted (a/k/a torn), I don't t
I saw this:
http://blog.pgaddict.com/posts/postgresql-on-ssd-4kb-or-8kB-pages
It made me wonder: if SSDs have 4kB/8kB sectors, and we'd make the Postgres
page size equal to the SSD page size, do we still need full_page_writes?
Regards
Marcin Mańk
>> Oct 5 15:00:25 db01 postgres[76648]: [5944-1] javafail@dbcluster 76648 0:
>> FATAL: pipe() failed: Too many open files in system
>
> This message must be coming from initSelfPipe(), and after poking around
> a bit I think the failure must be occurring while a new backend is
> attempting to d
> So that explains the crashes, but it doesn't (directly) explain why you
> had data corruption.
The first crash message:
Oct 5 15:00:21 db01 postgres[75852]: [6406-1] failjava@dbcluster 75852 0:
ERROR: could not seek to end of file "base/16387/18770": Too many open files
in system
Oct 5 15:
Sean Chittenden writes:
>> If you've got the postmaster logs from this episode, it would be useful
>> to see what complaints got logged.
> The first crash scenario:
> Oct 5 15:00:24 db01 postgres[75852]: [6449-2] javafail@dbcluster 75852 0:
> STATEMENT: SELECT /* query */ FROM tbl AS this_ WH
>> While the master was still being setup and data was being loaded, the
>> system ran out of open file descriptors and Pg crashed a few times
>> until this was realized and corrected.
>
> Could you provide a bit more detail than that? Usually the behavior we
> see under out-of-FDs conditions is
Sean Chittenden writes:
> While the master was still being setup and data was being loaded, the
> system ran out of open file descriptors and Pg crashed a few times
> until this was realized and corrected.
Could you provide a bit more detail than that? Usually the behavior we
see under out-of-FD
Master/slave replication, the master and slave both have full_page_writes
disabled because the system is running on ZFS.
While the master was still being setup and data was being loaded, the system
ran out of open file descriptors and Pg crashed a few times until this was
realized and corrected
Thanks Jeff. It makes sense now. I did a test with DBT2 by turning the
"full_page_write" on and off.
The argument is set to "-d 200 -w 1 -c 10" for a short test. There is
a 7 times difference in the number of pages written.
When the option is on, 1066 pages are written;
When the option is off, 15
On Wed, 2011-05-04 at 00:17 -0400, Tian Luo wrote:
> So, "nbytes" should always be multiples of XLOG_BLCKSZ, which in the
> default case, is 8192.
>
> My question is, if it always writes full pages no matter
> "full_page_writes" is on or off, what is the difference?
Most I/O systems and filesyste
Hi guys,
No matter I turn on or turn off the "full_page_writes", I always
observe 8192-byte writes of log data for simple write operations
(write/update).
But according to the document, when this is off, it could speed up
operations but may cause problems during recovery. So, I guess this is
bec
On Mon, 3 Dec 2007, Martin Marques wrote:
Out of ignorance, do RAID devices have write cache? I'm talking about
RAID through hardware.
Depends on the device. There are hardware RAID cards with cache, and ones
without. Generally the ones with cache allow you to adjust whether the
cache is u
Greg Smith escribió:
> On Sat, 1 Dec 2007, Tomasz Ostrowski wrote:
>
>> You can also use "hdparm -I" to check this - look for a "Write
>> caching" in "Commands/features" section. If it has a "*" in front
>> then it is enabled and dangerous.
>
> Right; using -I works with most Linux hdparm version
On Sat, 1 Dec 2007, Tomasz Ostrowski wrote:
You can also use "hdparm -I" to check this - look for a "Write
caching" in "Commands/features" section. If it has a "*" in front
then it is enabled and dangerous.
Right; using -I works with most Linux hdparm versions:
# hdparm -V
hdparm v6.6
# hdpar
On Sat, 01 Dec 2007, Martin Marques wrote:
>> Also check whether a disks have write-caching turned off - it should.
>> On Linux the command is:
>> # hdparm -W /dev/sda
>> /dev/sda:
>> write-caching = 0 (off)
>
> Uh? That command as was written lacks an argument for -W (0/1). From
Tomasz Ostrowski escribió:
On Sat, 01 Dec 2007, rihad wrote:
fsync = on;
synchronous_commit = off;
full_page_writes = off;
Thanks for any insights or clarifying missed points.
Also check whether a disks have write-caching turned off - it should.
On Linux the command is:
# hdparm -W /d
On Sat, 01 Dec 2007, rihad wrote:
> fsync = on;
> synchronous_commit = off;
> full_page_writes = off;
> Thanks for any insights or clarifying missed points.
Also check whether a disks have write-caching turned off - it should.
On Linux the command is:
# hdparm -W /dev/sda
/dev/sda
"rihad" <[EMAIL PROTECTED]> writes:
> Hi, would full_page_writes=off increase the risk of inconsistency or db
> corruption in 8.3 and FreeBSD 7?
yes.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
---
Hi, would full_page_writes=off increase the risk of inconsistency or db
corruption in 8.3 and FreeBSD 7?
fsync = on;
Definitely "on", as single power outage after three years is guaranteed
to make your life interesting otherwise.
synchronous_commit = off;
Can be "off" in my case as I'm not do
27 matches
Mail list logo
