Re: [PERFORM] BBU Cache vs. spindles

Tom Lane wrote: Uh, no, it is not. The difference is that we can update a byte in a shared buffer, and know that it *isn't* getting written out before we Well, I don't know where yu got the idea I was refering to that sort of thing - its the same as writing to a buffer before copying to the

Re: [PERFORM] anti-join chosen even when slower than old plan

On 11/11/10 9:13 AM, Mladen Gogala wrote: Kevin Grittner wrote: Mladen Gogala wrote: create a definitive bias toward one type of the execution plan. We're talking about trying to support the exact opposite. I understand this, that is precisely the reason for my intervention into the discu

Re: [PERFORM] Compared MS SQL 2000 to Postgresql 9.0 on Windows

On 12/7/10 9:34 AM, Tom Polak wrote: We are in the process of deciding on how to proceed on a database upgrade. We currently have MS SQL 2000 running on Windows 2003 (on my test server). I was shocked at the cost for MS SQL 2008 R2 for a new server (2 CPU license). I started comparing DB’s

Re: [PERFORM] Compared MS SQL 2000 to Postgresql 9.0 on Windows

On 12/7/10 1:29 PM, Tom Polak wrote: What I was really after was a quick comparison between the two. I did not create anything special, just the two tables. One table SQL generated the records for me. I did not tweak anything after installing either system. That's not a valid test. Postgres

Re: [PERFORM] Compared MS SQL 2000 to Postgresql 9.0 on Windows

On 12/17/10 9:08 AM, Tom Polak wrote: So, I am back on this topic again. I have a related question, but this might be the correct thread (and please let me know that). The boss is pressing the issue because of the cost of MSSQL. You need to analyze the total cost of the system. For the price

Re: [PERFORM] CPU bound

ust that the SSD is fast enough that the RAM is now the bottleneck, although parsing and text<=>binary conversions (especially for integers, reals and anything stored as an integer) also can be CPU-intensive. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- Sent via pgsql-perfor

Re: [PERFORM] CPU bound

iling the database code, which is not an option for a production MG> database. And how exactly, given that the kernel does not know whether the CPU is active or waiting on ram, could an application do so? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- Sent via pgsql-per

Re: [PERFORM] long wait times in ProcessCatchupEvent()

On 12/29/10 6:28 AM, Julian v. Bock wrote: I have the problem that on our servers it happens regularly under a certain workload (several times per minute) that all backend processes get a SIGUSR1 and spend several seconds in ProcessCatchupEvent(). At 100-200 connections (most of them idle) this c

Re: [PERFORM] long wait times in ProcessCatchupEvent()

On 12/29/10 11:58 AM, Tom Lane wrote: Craig James writes: On 12/29/10 6:28 AM, Julian v. Bock wrote: I have the problem that on our servers it happens regularly under a certain workload (several times per minute) that all backend processes get a SIGUSR1 and spend several seconds in

Re: [HACKERS] [PERFORM] Slow count(*) again...

On 2/3/11 1:34 PM, Shaun Thomas wrote: I must say that this purist attitude is extremely surprising to me. All the major DB vendors support optimizer hints, yet in the Postgres community, they are considered bad with almost religious fervor. Postgres community is quite unique with the fatwa again

Re: [PERFORM] Why we don't want hints Was: Slow count(*) again...

On 2/10/11 9:21 AM, Kevin Grittner wrote: Shaun Thomas wrote: how difficult would it be to add that syntax to the JOIN statement, for example? Something like this syntax?: JOIN WITH (correlation_factor=0.3) Where 1.0 might mean that for each value on the left there was only one distinct va

[PERFORM] Query on view radically slower than query on underlying table

We have a medium-sized catalog (about 5 million rows), but some of our customers only want to see portions of it. I've been experimenting with a customer-specific schema that contains nothing but a "join table" -- just the primary keys of that portion of the data that each customer wants to se

Re: [PERFORM] Query on view radically slower than query on underlying table

Craig James writes: Here is the "bad" query, which is run on the view: em=> explain analyze select version.version_id, version.isosmiles from hitlist_rows_reset_140 left join version on (hitlist_rows_reset_140.objectid = version.version_id) where hitlist_rows_reset_140.sorto

Re: [PERFORM] Xeon twice the performance of opteron

On 3/17/11 9:42 AM, J Sisson wrote: On Thu, Mar 17, 2011 at 10:13 AM, Jeff wrote: hey folks, Running into some odd performance issues between a few of our db boxes. We've noticed similar results both in OLTP and data warehousing conditions here. Opteron machines just seem to lag behind *espe

Re: [PERFORM] multiple table scan performance

On 3/29/11 3:16 PM, Samuel Gendler wrote: I've got some functionality that necessarily must scan a relatively large table. Even worse, the total workload is actually 3 similar, but different queries, each of which requires a table scan. They all have a resultset that has the same structure,

[PERFORM] Retaining execution plans between connections?

ges that use the same DB connection). Many thanks, James

[PERFORM] Sequential scan being used despite indexes

nly way I can think of forcing it to use the Index Scan in all cases would be to use two separate nested queries: The outer query would retrieve the list of messages in the forum, and the inner query would retrieve the list of metadata for an individual message. Obviously I want to avoid having to do that if possible. Any ideas? Many thanks if you can help. James

Re: [PERFORM] Sequential scan being used despite indexes

SeqScan as per the FAQ, and it indeed was a lot slower so Postgres was making the right choice in this case. Many thanks, James

[PERFORM] Basic Database Performance

appreciated! All the very best,   James Dey   tel   +27 11 704-1945 cell  +27 82 785-5102 fax   +27 11 388-8907 mail    [EMAIL PROTECTED]   myGUS / SLT retains all its intellectual property rights in any information contained in e-mail messages (or any attachments

Re: [PERFORM] Basic Database Performance

Sorry about that James Dey tel +27 11 704-1945 cell+27 82 785-5102 fax +27 11 388-8907 mail[EMAIL PROTECTED] -Original Message- From: Richard Huxton [mailto:[EMAIL PROTECTED] Sent: 10 February 2006 11:50 AM To: James Dey Cc: 'Postgresql Performance' S

[PERFORM] column totals

cient way? Kind Regards, James begin:vcard fn:James Neethling n:Neethling;James org:Silver Sphere Business Solutions adr:Centurion Business Park A2;;25633 Democracy Way;Prosperity Park;Milnerton;Cape Town;7441 email;internet:[EMAIL PROTECTED] title:Managing Member tel;work:27 21 552 7108 tel;fax:

Re: [PERFORM] column totals

James Neethling wrote: Hi There, I've got a situation where I need to pull profit information by product category, as well as the totals for each branch. Basically, something like SELECT branch_id, prod_cat_id, sum(prod_profit) as prod_cat_profit FROM () as b1 WHERE x = y GRO

Re: [PERFORM] Recommended File System Configuration

tails on how to properly conduct a filesystem benchmark and addresses scaling and load more so than Dr. Scalzo's tests. For further study, I have compiled a list of Linux filesystem resources at: http://jamesthornton.com/hotlist/linux-filesystems/. -- James Thornton __

[PERFORM] Adapting Oracle S.A.M.E. Methodology for Postgres

0_same.pdf). Has anyone delved into this before? -- James Thornton __ Internet Business Consultant, http://jamesthornton.com ---(end of broadcast)--- TIP 2: you can get off all lists at onc

[PERFORM] Recommended File System Configuration

slow, but this was improved with XFS 1.1. I think a journaling a FS is needed for PG data since large DBs could take hours to recover on a non-journaling FS, but what about WAL files? -- James Thornton __ Internet Business Consultant, http

Re: [PERFORM] linux distro for better pg performance

per goes over the details on how to properly conduct a filesystem benchmark and addresses scaling and load more so than Dr. Scalzo's tests. For further study, I have compiled a list of Linux filesystem resources at: http://jamesthornton.com/hotlist/linux-filesystems/. -- James Thornton __

[PERFORM] History of oids in postgres?

catalog in the oid-datatype doc page, but not regarding their history as 'user-space' row ids. Thanks, James James Robinson Socialserve.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ?

Re: [PERFORM] Quad processor options - summary

nto this before? -- James Thornton __ Internet Business Consultant, http://jamesthornton.com ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your j

Re: [PERFORM] Quad processor options - summary

e's no need to deallocate any blocks, and the underlying filesystem metadata doesn't even get touched." For further study, I have compiled a list of Linux filesystem resources at: http://jamesthornton.com/hotlist/linux-filesystems/. -- James Thornton ___

Re: [ADMIN] [PERFORM] Quad processor options - summary

stripe width will work well for the log files. In this case, the write operation will be buffered in cache and the next log writes can be issued before the previous write is destaged to disk." -- James Thornton __

[PERFORM] Query gets slow when where clause increases

;.tid) Filter: ((performed_on <= 1088480270::bigint) AND (userid = 1540)) -> Seq Scan on tickets t (cost=0.00..4538.35 rows=18823 width=12) (actual time=0.16..83.53 rows=6020 loops=2420) Filter: (((status <> 4::smallin

Re: [PERFORM] finding a max value

in postgresql, see... http://archives.postgresql.org/pgsql-performance/2003-12/msg00283.php -- # James Antill -- [EMAIL PROTECTED] :0: * ^From: [EMAIL PROTECTED] /dev/null ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choos

Re: [PERFORM] my boss want to migrate to ORACLE

t RAID 10, not RAID 0. -- James Thornton __ Internet Business Consultant, http://jamesthornton.com ---(end of broadcast)--- TIP 8: explain analyze is your friend

[PERFORM] Efficient way to remove OID data

Title: Message I have a table that has 2 columns of an OID type.  I would like to issue a truncate table command but my understanding is that the data pointed to by the OIDs is not removed and orphaned.  What would be the most efficient way to truncate the table and not have orphaned data?  

[PERFORM] Upgrading from from 7.4.2 to 8.0

Title: Message Will I have to dump and reload all my databases when migrating from 7.4.2 to 8.0?     Jim Gunzelman Senior Software Engineer   phone: 402.361.3078   fax: 402.361.3178 e-mail:  JamesGunzelman[EMAIL PROTECTED]   Solutionary, Inc. www.Solutio

[PERFORM] Is ANALYZE transactional?

If I do: begin; update some_table set foo = newvalue where a_bunch_of_rows_are_changed; analyze some_table; rollback; does it roll back the statistics? (I think the answer is yes, but I need to be sure.) Thanks, Craig ---(end of broadcast)-

Re: [PERFORM] Curious about dead rows.

Alvaro Herrera wrote: To recap: - your app only does inserts - there has been no rollback lately - there are no updates - there are no deletes The only other source of dead rows I can think is triggers ... do you have any? (Not necessarily on this table -- perhaps triggers on other tables can

Re: [PERFORM] Query only slow on first run

tmp wrote: what exactly is that "random_number" column A random float that is initialized when the row is created and never modified afterwards. The physical row ordering will clearly not match the random_number ordering. However, other queries uses a row ordering by the primary key so I don

Re: [PERFORM] RAID arrays and performance

nts out of the query evaluator thread, and so on. Parallel threading queries is a whle different ball game which needs thought in the optimiser. James ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an a

Re: [PERFORM] RAID arrays and performance

Mark Mielke wrote: This assumes that you can know which pages to fetch ahead of time - which you do not except for sequential read of a single table. Why doesn't it help to issue IO ahead-of-time requests when you are scanning an index? You can read-ahead in index pages, and submit requests f

Re: [PERFORM] RAID arrays and performance

st be demand loaded. I'm not suggesting that Postgres indices are structured in a way that would support this sort of thing now. James ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subs

Re: [PERFORM] RAID arrays and performance

Mark Mielke wrote: PostgreSQL or the kernel should already have the hottest pages in memory, so the value of doing async I/O is very likely the cooler pages that are unique to the query. We don't know what the cooler pages are until we follow three tree down. I'm assuming that at the time we

[PERFORM] libgcc double-free, backend won't die

This is driving me crazy. I have some Postgres C function extensions in a shared library. They've been working fine. I upgraded to Fedora Core 6 and gcc4, and now every time psql(1) disconnects from the server, the serverlog gets this message: *** glibc detected *** postgres: mydb mydb [l

Re: [PERFORM] libgcc double-free, backend won't die

Alvaro Herrera wrote: Craig James wrote: This is driving me crazy. I have some Postgres C function extensions in a shared library. They've been working fine. I upgraded to Fedora Core 6 and gcc4, and now every time psql(1) disconnects from the server, the serverlog gets this me

Re: [PERFORM] libgcc double-free, backend won't die

Tom Lane wrote: Craig James <[EMAIL PROTECTED]> writes: This is driving me crazy. I have some Postgres C function extensions in a shared library. They've been working fine. I upgraded to Fedora Core 6 and gcc4, and now every time psql(1) disconnects from the server, the serv

Re: [PERFORM] libgcc double-free, backend won't die

Alvaro Herrera wrote: Craig James wrote: Here is my guess -- and this is just a guess. My functions use a third-party library which, of necessity, uses malloc/free in the ordinary way. I suspect that there's a bug in the Postgres palloc() code that's walking over memory that regu

Re: [PERFORM] libgcc double-free, backend won't die

Alvaro Herrera wrote: Craig James wrote: Alvaro Herrera wrote: Craig James wrote: Here is my guess -- and this is just a guess. My functions use a third-party library which, of necessity, uses malloc/free in the ordinary way. I suspect that there's a bug in the Postgres palloc()

Re: [PERFORM] libgcc double-free, backend won't die

Alvaro Herrera wrote: ...Since you've now shown that OpenBabel is multithreaded, then that's a much more likely cause. Can you elaborate? Are multithreaded libraries not allowed to be linked to Postgres? Absolutely not. Ok, thanks, I'll work on recompiling OpenBabel without thread support.

Re: [PERFORM] libgcc double-free, backend won't die

Tom Lane wrote: Craig James <[EMAIL PROTECTED]> writes: GNU gdb Red Hat Linux (6.5-15.fc6rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under c

Re: [PERFORM] libgcc double-free, backend won't die

Tom Lane wrote: Magnus Hagander <[EMAIL PROTECTED]> writes: On Tue, Dec 11, 2007 at 07:50:17AM -0800, Craig James wrote: Since I'm not a Postgres developer, perhaps one of the maintainers could update the Postgres manual. In chapter 32.9.6, it says, "To be precise, a shared

Re: [PERFORM] libgcc double-free, backend won't die

of a threaded library (in particular, the runtimes for most embeddable languages, or libraries for RPC runtimes, etc) to 'modern' platforms that support threads effectively. On many such platforms these will already implicitly link libpthread anyway. James

Re: [PERFORM] libgcc double-free, backend won't die

Gregory Stark wrote: "Tom Lane" <[EMAIL PROTECTED]> writes: James Mansion <[EMAIL PROTECTED]> writes: Is there any particular reason not to ensure that any low-level threading support in libc is enabled right from the get-go, as a build-time option? Yes. 1) It's

Re: [PERFORM] libgcc double-free, backend won't die

tgres procs is one of the advantages of the system itself. (I'd like to discount the use of a runtime in a seperate process - the latency is a problem for row triggers and functions) James ---(end of broadcast)--- TIP 7: You can help

[PERFORM] Multi-threading friendliness (was: libgcc double-free, backend won't die)

Bruce Momjian wrote: James Mansion wrote: I think you have your head in the ground, but its your perogative. *You* might not care, but anyone wanting to use thread-aware libraries (and I'm *not* talking about threading in any Postgres code) will certainly value it if they can do so with

Re: [PERFORM] Multi-threading friendliness

Craig James wrote: Don't confuse thread-friendly with a threaded implemetation of Postgres itself. These are two separate questions. Thread-friendly involves compile/link options that don't affect the Postgres source code at all. Indeed. I'm specifically not suggesting that

Re: [PERFORM] Linux/PostgreSQL scalability issue - problem with 8 cores

Jakub Ouhrabka wrote: How can we diagnose what is happening during the peaks? Can you try forcing a core from a bunch of the busy processes? (Hmm - does Linux have an equivalent to the useful Solaris pstacks?) James ---(end of broadcast

[PERFORM] Simple select, but takes long time

Hi, I am having a really hard time trying to figure out why my simple count(*) query is taking so long. I have a table with 1,296,070 rows in it. There are 2 different types of information that each row has that I care about: status : character(1) source_id : bigint Then, I have the follo

Re: [PERFORM] Making the most of memory?

Guy Rouillier wrote: Scott Marlowe wrote: I assume you're talking about solid state drives? They have their uses, but for most use cases, having plenty of RAM in your server will be a better way to spend your money. For certain high throughput, relatively small databases (i.e. transactional wo

Re: [PERFORM] 8x2.5" or 6x3.5" disks

Mike Smith wrote: I’ve seen a few performance posts on using different hardware technologies to gain improvements. Most of those comments are on raid, interface and rotation speed. One area that doesn’t seem to have been mentioned is to run your disks empty. ... On the outside of the dis

[PERFORM] Dell Perc/6

Does anyone have performance info about the new Dell Perc/6 controllers? I found a long discussion ("Dell vs HP") about the Perc/5, but nothing about Perc/6. What's under the covers? Here is the (abbreviated) info from Dell on this machine: PowerEdge 1950 IIIQuad Core Intel® Xeon® E5

Re: [PERFORM] LISTEN / NOTIFY performance in 8.3

n we could write our own mechanisms. James ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Re: [PERFORM] LISTEN / NOTIFY performance in 8.3

Tom Lane wrote: Hardly --- how's that going to pass a notify name? Also, a lot of people want some payload data in a notify, not just a condition name; any reimplementation that doesn't address that desire probably won't get accepted. Ah - forgot about the name. At least there need be just o

[PERFORM] How to allocate 8 disks

We're upgrading to a medium-sized server, a Dell PowerEdge 2950, dual-quad CPU's and 8 GB memory. This box can hold at most 8 disks (10K SCSI 2.5" 146 GB drives) and has Dell's Perc 6/i RAID controller. I'm thinking of this: 6 disks RAID 1+0 Postgres data 1 disk WAL 1 disk Linux I'v

Re: [PERFORM] How to allocate 8 disks

Joshua D. Drake wrote: On Sat, 01 Mar 2008 10:06:54 -0800 Craig James <[EMAIL PROTECTED]> wrote: We're upgrading to a medium-sized server, a Dell PowerEdge 2950, dual-quad CPU's and 8 GB memory. This box can hold at most 8 disks (10K SCSI 2.5" 146 GB drives) and has

Re: [PERFORM] How to allocate 8 disks

Matthew wrote: On Sat, 1 Mar 2008, Craig James wrote: Right, I do understand that, but reliability is not a top priority in this system. The database will be replicated, and can be reproduced from the raw data. So what you're saying is: 1. Reliability is not important. 2. There&#

Re: [PERFORM] count * performance issue

In the 3 years I've been using Postgres, the problem of count() performance has come up more times than I can recall, and each time the answer is, "It's a sequential scan -- redesign your application." My question is: What do the other databases do that Postgres can't do, and why not? Count()

Re: [PERFORM] count * performance issue

Tom Lane wrote: Craig James <[EMAIL PROTECTED]> writes: Count() on Oracle and MySQL is almost instantaneous, even for very large tables. So why can't Postgres do what they do? AFAIK the above claim is false for Oracle. They have the same transactional issues we do. My experie

[PERFORM] Benchmark: Dell/Perc 6, 8 disk RAID 10

I just received a new server and thought benchmarks would be interesting. I think this looks pretty good, but maybe there are some suggestions about the configuration file. This is a web app, a mix of read/write, where writes tend to be "insert into ... (select ...)" where the resulting inser

Re: [PERFORM] Repeated execution of identical subqueries

Craig Ringer wrote: Tom Lane wrote: No, not at the moment. In principle the planner could look for such duplicates, but it'd be wasted cycles so much of the time that I'd be loath to do it. Good point - there are better places to spend time, and I imagine it'd be an expensive thing to check

Re: [PERFORM] Benchmark: Dell/Perc 6, 8 disk RAID 10

card in some "normal" mode that doesn't take advantage of its capabilities. With a 6-disk RAID 10, you should get numbers at least in the same ballpark as my numbers. Craig Message from Craig James <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> at 03-12-2008

Re: [PERFORM] Benchmark: Dell/Perc 6, 8 disk RAID 10

RAID card . I have the cache turned on with Read Ahead Message from Craig James <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> at 03-12-2008 09:55:18 PM -- I just received a new server and thought benchmarks would be interesting. I think this looks pretty go

Re: [PERFORM] Benchmark: Dell/Perc 6, 8 disk RAID 10

Joshua D. Drake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 12 Mar 2008 21:55:18 -0700 Craig James <[EMAIL PROTECTED]> wrote: Diffs from original configuration: max_connections = 1000 shared_buffers = 400MB work_mem = 256MB max_fsm_pages = 100 max_fsm_relations

[PERFORM] temp tables

Do CREATE TEMP TABLE table have any special treatment regarding eliding sync operations or deferring creation of disk files in the case where memory pressure does not require a spill? James -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your

Re: [PERFORM] What is the best way to storage music files in Postgresql

Rich wrote: I am going to embarkon building a music library using apache, postgresql and php. What is the best way to store the music files? Which file type should I use? In Postgres, its all just binary data. It's entirely up to you which particular format you use. mp2, mp3 mp4, wmv, avi, w

Re: [PERFORM] Benchmark: Dell/Perc 6, 8 disk RAID 10

Dave Cramer wrote: On 16-Mar-08, at 2:19 AM, Justin wrote: I decided to reformat the raid 10 into ext2 to see if there was any real big difference in performance as some people have noted here is the test results please note the WAL files are still on the raid 0 set which is still in e

Re: [PERFORM] Benchmark: Dell/Perc 6, 8 disk RAID 10

Craig James wrote: Dave Cramer wrote: On 16-Mar-08, at 2:19 AM, Justin wrote: I decided to reformat the raid 10 into ext2 to see if there was any real big difference in performance as some people have noted here is the test results please note the WAL files are still on the raid 0 set

Re: [PERFORM] Benchmark: Dell/Perc 6, 8 disk RAID 10

Justin wrote: 2000 tps ??? do you have fsync turned off ? Dave No its turned on. Unless I'm seriously confused, something is wrong with these numbers. That's the sort of performance you expect from a good-sized RAID 10 six-disk array. With a single 7200 rpm SATA disk and XFS, I get 640

Re: [PERFORM] Benchmark: Dell/Perc 6, 8 disk RAID 10

[EMAIL PROTECTED] wrote: WAL is on a RAID 0 drive along with the OS Isn't that just as unsafe as having the whole lot on RAID0? -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-perform

Re: [PERFORM] Planning a new server - help needed

ss is 10ms, and you write 100MB/s streaming, then you have to ask yourself if you going to do 80 or more seeks a second. James James -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Planning a new server - help needed

early get rewritten often. I suspect a mix of storage technologies will be handy for some time yet - WAL on disk, and temp tables on disk with no synchronous fsync requirement. I think life is about to get interesting in DBMS storage. All good for us users. James -- Sent via pgsql-pe

[PERFORM] POSIX file updates

(Declaration of interest: I'm researching for a publication on OLTP system design) I have a question about file writes, particularly on POSIX. This arose while considering the extent to which cache memory and command queueing on disk drives can help improve performance. Is it correct that POSIX

Re: [PERFORM] POSIX file updates

) will be prompted to remember. It may have been something in a blog related to ZFS vs other filesystems, but so far I'm coming up empty in google. doesn't feel like something I imagined though. James -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.or

Re: [PERFORM] POSIX file updates

I don't believe POSIX has any restriction such as you describe - or if it does, and I don't know about it, then most UNIX file systems (if not most file systems on any platform) are not POSIX compliant. I suspect that indeed there are two different issues here in that the file mutex relates

Re: [PERFORM] POSIX file updates

Mark Mielke wrote: Is there anything in POSIX that seems to suggest this? :-) (i.e. why are you going under the assumption that the answer is yes - did you read something?) Perhaps it was just this: http://kevinclosson.wordpress.com/2007/01/18/yes-direct-io-means-concurrent-writes-oracle-doe

[PERFORM] SSDs

Tried harder to find info on the write cycles: found som CFs that claim 2million cycles, and found the Mtron SSDs which claim to have very advanced wear levelling and a suitably long lifetime as a result even with an assumption that the underlying flash can do 100k writes only. The 'consumer'

Re: [PERFORM] POSIX file updates

com/html/advanced.html#transaction_isolation http://lwn.net/Articles/270891/ http://article.gmane.org/gmane.linux.kernel/646040 http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html http://brad.livejournal.com/2116715.html And your handy document on wal tuning, of course. James -- Se

Re: [PERFORM] Performance Implications of Using Exceptions

Stephen Denne wrote: A third option is to update, if not found, insert. I find myself having to do this in Sybase, but it sucks because there's a race - if there's no row updated then there's no lock and you race another thread doing the same thing. So you grab a row lock on a sacrificial ro

Re: [PERFORM] POSIX file updates

Andreas Kostyrka wrote: takes over. The thing you worry about is if all data has made it to the replication servers, not if some data might get lost in the hardware cache of a controller. (Actually, talk to your local computer forensics guru, there are a number of way to keep the current to elect

Re: [PERFORM] POSIX file updates

rocess if you must) or aio. There are plenty of cases where the so-called "lying" drives themselves are completely stupid on their own regardless of operating system. With modern NCQ capable drive firmware? Or just with older PATA stuff? There's an awful lot of fud out there a

Re: [PERFORM] Performance Implications of Using Exceptions

Robins Tharakan wrote: I think James was talking about Sybase. Postgresql on the other hand has a slightly better way to do this. SELECT ... FOR UPDATE allows you to lock a given row (based on the SELECT ... WHERE clause) and update it... without worrying about a concurrent modification

Re: [PERFORM] Anybody using the Dell Powervault MD3000 array?

Gavin M. Roy wrote: On Wed, Apr 16, 2008 at 4:39 PM, Joshua D. Drake <[EMAIL PROTECTED] > wrote: On Wed, 16 Apr 2008 13:37:32 -0700 "Jeffrey Baker" <[EMAIL PROTECTED] > wrote: > > I can second this. The MSA 70 is a great unit fo

[PERFORM] full_page_write and also compressed logging

s for ZFS (http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/os/compress.c). Would work well for largely textual tables (and I suspect a lot of integer data too). James -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to yo

Re: [PERFORM] Background writer underemphasized ...

And if the buffer backed up in the BGW case, wouldn't it also back up (more?) if the writes are deferred? And in fact by sending earlier, the real bottleneck (the disks) could have been getting on with it and staring their IO earlier? Can you explian your reasoning a bit more? James --

Re: [PERFORM] Background writer underemphasized ...

existing elevator plan until it is completed and it looks at the new requests? This sounds a bit tenuous at best - almost to the point of being a bug. Do you believe this is universal? James -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make

Re: [PERFORM] two memory-consuming postgres processes

On Fri, May 2, 2008 at 2:26 PM, Alexy Khrabrov <[EMAIL PROTECTED]> wrote: I naively thought that if I have a 100,000,000 row table, of the form (integer,integer,smallint,date), and add a real coumn to it, it will scroll through the memory reasonably fast. In Postgres, an update is the same as

Re: [PERFORM] Backup causing poor performance - suggestions

Campbell, Lance wrote: We currently backup all of our database tables per schema using pg_dump every half hour. We have been noticing that the database performance has been very poor during the backup process. How can I improve the performance? It sounds like the goal is to have frequent, n

[PERFORM] RAID 10 Benchmark with different I/O schedulers (was: Performance increase with elevator=deadline)

I had the opportunity to do more testing on another new server to see whether the kernel's I/O scheduling makes any difference. Conclusion: On a battery-backed RAID 10 system, the kernel's I/O scheduling algorithm has no effect. This makes sense, since a battery-backed cache will supercede an

Re: [PERFORM] What constitutes a complex query

Justin wrote: This falls under the stupid question and i'm just curious what other people think what makes a query complex? There are two kinds: 1. Hard for Postgres to get the answer. 2. Hard for a person to comprehend. Which do you mean? Craig -- Sent via pgsql-performance mailing list (

Re: [PERFORM] RAID 10 Benchmark with different I/O schedulers

Greg Smith wrote: On Mon, 5 May 2008, Craig James wrote: pgbench -i -s 20 -U test That's way too low to expect you'll see a difference in I/O schedulers. A scale of 20 is giving you a 320MB database, you can fit the whole thing in RAM and almost all of it on your controller cach

Re: [PERFORM] RAID 10 Benchmark with different I/O schedulers

Greg Smith wrote: On Tue, 6 May 2008, Craig James wrote: I only did two runs of each, which took about 24 minutes. Like the first round of tests, the "noise" in the measurements (about 10%) exceeds the difference between scheduler-algorithm performance, except that "anticip

<    1   2   3   4   5   6   >