Re: [PERFORM] select on 22 GB table causes "An I/O error occured while sending to the backend." exception

increase the timeout settings on the insert connections that are failing? -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz -- 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] The state of PG replication in 2008/Q2?

sters. -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz -- 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] Adding "LIMIT 1" kills performance.

ER JOIN calendar_links ON calendars.id = calendar_links.source_tracker_id WHERE (calendar_links.calendar_group_id = 3640) ORDER BY event_updates.id DESC ) AS foo LIMIT 1; -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz -- Sent via pgsql-performance mailing list (pgs

Re: [PERFORM] Varchar pkey instead of integer

will come into effect each time you reference that column. -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz -- 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] Fastest way / best practice to calculate "next birthdays"

Time: 483.915 ms -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz -- 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] Replication Syatem

8.1.3. HOT is only available in 8.3 and 8.3.1 You DO need to upgrade to get the benefits of HOT -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription:

Re: [PERFORM] Replication Syatem

find this will reclaim some disk space for you as well. -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/

Re: [PERFORM] Very poor performance loading 100M of sql data using copy

check constraints, indexes, and modify the rules/triggers to handle the inserts to the parent table. -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription:

Re: [PERFORM] [PERFORMANCE] Error loading 37G CSV file "invalid string enlargement request size 65536"

till be working as you load data? If the db is not in use try dropping all indexes (on the relevant table anyway), loading then create indexes. You can copy into a temp table without indexes then select into the target table. What fk restraints does this table have? Can they be safely deferred

Re: [PERFORM] how can a couple of expensive queries drag my system down?

e defs you can get some useful feedback here. If there is no way of improving them then look at a reporting slave. -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make cha

Re: [PERFORM] How to allocate 8 disks

to get you past hardware failures that happen at the wrong time. (as they all do) -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your Subscription: http://mail.postgresql.o

Re: [PERFORM] 12 disks raid setup

ging the cache options. If the raid card has the cache without the battery you would get the performance figures you mentioned, you just wouldn't have the reliability of finishing writes after a power off situation. correct me if I am wrong here. -- Shane Ambler pgSQ

Re: [PERFORM] store A LOT of 3-tuples for comparisons

"he", "can" and should they be considered the same? If so you will need a different tactic. -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [PERFORM] Seq scans on indexed columns.

g idx_comment_parent_id on _comment (cost=0.00..135.61 rows=79 width=8) Index Cond: (parent_id = $0) -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] With 4 disks should I go for RAID 5 or RAID 10

Greg Smith wrote: On Thu, 27 Dec 2007, Shane Ambler wrote: So in theory a modern RAID 1 setup can be configured to get similar read speeds as RAID 0 but would still drop to single disk speeds (or similar) when writing, but RAID 0 can get the faster write performance. The trick is, you need

Re: [PERFORM] With 4 disks should I go for RAID 5 or RAID 10

Mark Mielke wrote: Shane Ambler wrote: So in a perfect setup (probably 1+0) 4x 300MB/s SATA drives could deliver 1200MB/s of data to RAM, which is also assuming that all 4 channels have their own data path to RAM and aren't sharing. (anyone know how segregated the on board controllers su

Re: [PERFORM] With 4 disks should I go for RAID 5 or RAID 10

speeds so different that this theory is real fantasy or has hardware reached a point performance wise where this is close to fact?? -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz ---(end of broadcast)--- TIP 5: don&

Re: [PERFORM] PostgreSQL vs MySQL, and FreeBSD

o they can have one to work on. -- Shane Ambler [EMAIL PROTECTED] Get Sheeky @ http://Sheeky.Biz ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [PERFORM] Problems with + 1 million record table

DSUBGRUPONESTLE" DOUBLE PRECISION, "CODFAMILIANESTLE" DOUBLE PRECISION, "QTPESOPREV" DOUBLE PRECISION, "QTVENDAPREV" DOUBLE PRECISION, "VLVENDAPREV" DOUBLE PRECISION, "QT" DOUBLE PRECISION, "PUNIT" DOUBLE PRECIS

Re: [PERFORM] Usage up to 50% CPU

g and watching the cpu usage, your query would seem to taking a while to run, leading me to wonder if you are getting a full table scan that is causing pg to wait for disk response? Or are you running a long list of steps that take a while? -- Shane Ambler [EMAIL PROTECTED] Get Sheeky @

Re: [PERFORM] Any advantage to integer vs stored date w. timestamp

it for each query. But with disks and ram as cheap as they are these days this sort of packing is getting rarer (except maybe embedded systems with limited resources) My current scheme, though as normalized and summarized as I can make it, really chews up a ton of space. It might even

Re: [PERFORM] Two hard drives --- what to do with them?

these - as long as the drive's write cache is off - the raid card will hold data that was sent to disk until it confirms it is written to disk. The battery backup will even hold that data until the machine is switched back on when it completes the writing to di

Re: [PERFORM] Two hard drives --- what to do with them?

is is another advantage of SCSI disks - they honor these settings as you would expect - many IDE/SATA disks often say "sure I'll disable the cache" but continue to use it or don't retain the setting after restart. -- Shane Ambler [EMAIL PROTECTED] Get Sheeky

Re: [PERFORM] trouble with a join on OS X

other apps on OS X, and I have never been convinced that they behaved as true 64 bit. I haven't tried myself -- Shane Ambler [EMAIL PROTECTED] Get Sheeky @ http://Sheeky.Biz ---(end of broadcast)--- TIP 3: Have you checked our ext

Re: [PERFORM] trouble with a join on OS X

e out of memory errors (or is postgres get around that with it's caching?). -- Shane Ambler [EMAIL PROTECTED] Get Sheeky @ http://Sheeky.Biz ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings

Re: [PERFORM] High update activity, PostgreSQL vs BigDBMS

select/update's designed to take advantage of PostgreSQL strengths can give you performance improvements. -- Shane Ambler [EMAIL PROTECTED] Get Sheeky @ http://Sheeky.Biz ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [PERFORM] Areca 1260 Performance

, and the largest they carry fits 16 drives. Chenbro has a 24 drive case - the largest I have seen. It fits the big 4/8 cpu boards as well. http://www.chenbro.com/corporatesite/products_01features.php?serno=43 -- Shane Ambler [EMAIL PROTECTED] Get Sheeky @ http://Sheek

Re: [PERFORM] Keeping processes open for re-use

for your needs. Basically replace pg_connect with pg_pconnect Other languages may have a similar option. http://php.net/manual/en/features.persistent-connections.php -- Shane Ambler [EMAIL PROTECTED] Get Sheeky @ http://Sheeky.Biz ---(end of broadcast)

Re: [PERFORM] New hardware thoughts

RAID 10 setups. This can give you the reliability and speed with system and xlog on one and data on the other. Sounds to me like you have it worked out even if you are a little indecisive on a couple of finer points. -- Shane Ambler [EMAIL PROTECTED] Get Sheeky @ http://Sh

Re: [PERFORM] Optimization of this SQL sentence

Christopher Browne wrote: The world rejoiced as [EMAIL PROTECTED] (Shane Ambler) wrote: Chris Browne wrote: In the case of a zip code? Sure. US zip codes are integer values either 5 or 9 characters long. So your app will only work in the US? And only for US companies that only have US

Re: [PERFORM] Optimization of this SQL sentence

Chris Browne wrote: In the case of a zip code? Sure. US zip codes are integer values either 5 or 9 characters long. So your app will only work in the US? And only for US companies that only have US clients? Sorry had to dig at that ;-P -- Shane Ambler [EMAIL PROTECTED] Get Sheeky