Re: [PERFORM] concurrent IO in postgres?
On Thu, Dec 23, 2010 at 11:46 AM, Przemek Wozniak wozn...@lanl.gov wrote: In one test I was running between 1 and 32 clients simultaneously writing lots of data using copy binary. Are you by-passing WAL? If not, you are likely serializing on that. Not so much the writing, but the lock. The problem is that with a large RAM buffer it all goes there, and then the background writer, a single postgres process, will issue write requests one at a time I suspect. But those writes are probably just copies of 8K into kernel's RAM, and so very fast. So the actual IO is effectively serialized by the backend. If the background writer cannot keep up, then the individual backends start doing writes as well, so it isn't really serialized.. Cheers, Jeff -- 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] concurrent IO in postgres?
Jeff Janes wrote: If the background writer cannot keep up, then the individual backends start doing writes as well, so it isn't really serialized.. Is there any parameter governing that behavior? Can you tell me where in the code (version 9.0.2) can I find that? Thanks. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- 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] encourging bitmap AND
On Thu, Dec 23, 2010 at 22:52, Tom Lane t...@sss.pgh.pa.us wrote: Ben midfi...@gmail.com writes: i have a schema similar to the following create index foo_s_idx on foo using btree (s); create index foo_e_idx on foo using btree (e); i want to do queries like select * from foo where 150 between s and e; That index structure is really entirely unsuited to what you want to do, so it's not surprising that the planner isn't impressed with the idea of a bitmap AND. Why is it unsuited for this query? It expands to (150 s AND 150 e) which should work nicely with bitmap AND as far as I can tell. Regards, Marti -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
