[PERFORM] Regarding mulitple rows insert in one shot using ADO .net connected to postgres

2009-10-08 Thread keshav upadhyaya
Hi , I want to insert multiple Rows in one shot to improve my performance . From C# code I am using ADO .net to connect to postgres . Currently i am pasting the code which is not of postgres but in my dev environment similar things i am doing with Postgres. MySqlConnection mySql = new

[PERFORM] Query logging time, not values

2009-10-08 Thread Ludwik Dylag
HiI have a database and ~150 clients non-stop writing to this database quite big pieces of text. I have a performacne problem so I tried to increase log level, so I could see which queries take most time. My postgresql.conf (Log section) is: log_destination = 'stderr' logging_collector = on

Re: [PERFORM] Best suiting OS

2009-10-08 Thread Matthew Wakeling
On Mon, 5 Oct 2009, Jean-Michel Pouré wrote: Go for Debian: * It is a free community, very active. * It is guaranteed to be upgradable. * Very easy to administrate via apt-get. http://www.debian.org/News/2009/20091007 If you like Debian, but want to use FreeBSD, now you can have both.

[PERFORM] position in DDL of columns used in indexes

2009-10-08 Thread Michael Gould
In other SQL engines that I've used, it is recommended that the columns that are used in various indexes be placed at the beginning of a row since at some point (depending on the engine and/or pagesize) wide rows could end up on other pages.  From a performance standpoint on large tables this

Re: [PERFORM] position in DDL of columns used in indexes

2009-10-08 Thread Matthew Wakeling
On Thu, 8 Oct 2009, Michael Gould wrote: In other SQL engines that I've used, it is recommended that the columns that are used in various indexes be placed at the beginning of a row since at some point (depending on the engine and/or pagesize) wide rows could end up on other pages.  From a

Re: [PERFORM] position in DDL of columns used in indexes

2009-10-08 Thread Tom Lane
Matthew Wakeling matt...@flymine.org writes: Postgres does not split rows across multiple pages, so this should never be a concern. When a row is too big for a page, Postgres will select the larger of the columns from the row and compress them. If that fails to bring the row size down, then

[PERFORM] Partitioned Tables and ORDER BY

2009-10-08 Thread Joe Uhl
We have been using partitioning for some time with great success. Up until now our usage has not included ordering and now that we are trying to use an ORDER BY against an indexed column a rather significant shortcoming seems to be kicking in. Parent table (have cut all but 4 columns to make

[PERFORM] concurrent reindex issues

2009-10-08 Thread Tory M Blue
Hey all, it's been a bit however I'm running into some issues with my concurrent index Always get this error during a concurrent index. *2009-10-07 22:18:02 PDT admissionclsdb postgres 10.13.200.70(46706) ERROR: deadlock detected* *2009-10-07 22:18:02 PDT admissionclsdb postgres

Re: [PERFORM] dump time increase by 1h with new kernel

2009-10-08 Thread Justin T Pryzby
Hi Everyone On Fri, Oct 02, 2009 at 12:58:12PM -0700, Justin Pryzby wrote: When we upgraded from linux-2.6.24 to linux-2.6.27, our pg_dump duration increased by 20% from 5 hours to 6. My first attempt at On Sat, Oct 03, 2009 at 11:31:11PM -0600, Scott Marlowe wrote: between these two to tell

Re: [PERFORM] dump time increase by 1h with new kernel

2009-10-08 Thread Joshua D. Drake
On Thu, 2009-10-08 at 10:44 -0700, Justin T Pryzby wrote: Hi Everyone Did your scheduler change between the kernel versions? Not sure if sar can provide other data included by vmstat: IO merged in/out, {,soft}irq ticks? Thanks, Justin -- PostgreSQL.org Major Contributor Command

Re: [PERFORM] concurrent reindex issues

2009-10-08 Thread Tom Lane
Tory M Blue tmb...@gmail.com writes: *2009-10-07 22:18:02 PDT admissionclsdb postgres 10.13.200.70(46706) ERROR: deadlock detected* *2009-10-07 22:18:02 PDT admissionclsdb postgres 10.13.200.70(46706) DETAIL: Process 20939 waits for ShareLock on virtual transaction 16/43817381; blocked by

Re: [PERFORM] concurrent reindex issues

2009-10-08 Thread Scott Marlowe
On Thu, Oct 8, 2009 at 11:55 AM, Tom Lane t...@sss.pgh.pa.us wrote: I wouldn't be too surprised if the LOCK is coming from some Slony operation or other.  You might want to ask the slony hackers about it. I've had issues like this. Shutting down the slon daemons before running such commands

Re: [PERFORM] dump time increase by 1h with new kernel

2009-10-08 Thread Justin T Pryzby
On Thu, Oct 08, 2009 at 10:49:37AM -0700, Joshua D. Drake wrote: On Thu, 2009-10-08 at 10:44 -0700, Justin T Pryzby wrote: Hi Everyone Did your scheduler change between the kernel versions? No, it's deadline for both. Justin -- Sent via pgsql-performance mailing list

[PERFORM] Explain Analyze returns faster than psql or JDBC calls.

2009-10-08 Thread G B
Hi there We are runing Postgres 8.3.7 on a We have a problem with Explain Analyze that we haven't seen before. we run an Explain Analyze on a query. Nested Loop (cost=1256.32..2097.31 rows=198 width=1120) (actual time=12.958..20.846 rows=494 loops=1) - HashAggregate

Re: [PERFORM] dump time increase by 1h with new kernel

2009-10-08 Thread Kevin Grittner
Justin T Pryzby just...@norchemlab.com wrote: On Thu, Oct 08, 2009 at 10:49:37AM -0700, Joshua D. Drake wrote: Did your scheduler change between the kernel versions? No, it's deadline for both. How about write barriers? I had a kernel upgrade which turned them on for xfs, with unfortunate

Re: [PERFORM] dump time increase by 1h with new kernel

2009-10-08 Thread Justin T Pryzby
On Thu, Oct 08, 2009 at 03:37:39PM -0500, Kevin Grittner wrote: Justin T Pryzby just...@norchemlab.com wrote: On Thu, Oct 08, 2009 at 10:49:37AM -0700, Joshua D. Drake wrote: Did your scheduler change between the kernel versions? No, it's deadline for both. How about write barriers? I

Re: [PERFORM] Explain Analyze returns faster than psql or JDBC calls.

2009-10-08 Thread Tom Lane
G B g.b.co...@gmail.com writes: How can explain-analyze return significantly much faster than other means? If the returned data is large or takes a lot of work to convert to text, this could happen, since EXPLAIN ANALYZE doesn't bother to format the tuples for display. How big are those bytea