Re: [PERFORM] Caching by Postgres

comfortable caching data pages from files above the 32-bit mark. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ .

Re: [PERFORM] Caching by Postgres

I've been looking at switching to 64-bit, mostly to benefit from the better motherboard bandwidth, and just to play around. I'm not expecting to require the 64-bit instructions. Hope this helps, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] _

Re: [PERFORM] Caching by Postgres

lify my statements. :-) But yeah, I agree. It's a lot of hype, for not much gain (and some loss, depending on what it is being used for). I only want one because they're built better, and because I want to play around. Cheers, mark -- [EMAIL PROTECTED]

Re: [PERFORM] Caching by Postgres

;P to CS > undergrads, but I'm fairly sure the details are all the same for MIPS > processors as well. Smart design, that obscures the difference - but doesn't make the difference a myth. If it's already there, then it's

Re: [PERFORM] When to do a vacuum for highly active table

- but they do work differently, and for certain uses, one can destroy the other. Using a MyISAM table would be the way I would go with this sort of problem. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] _

Re: [PERFORM] 'Real' auto vacuum?

ed up by a batch run of vacuum. If it's free though - let's do it now. I think any optimizations we come up with, will be more happily accepted with a working patch that causes no breakage...

Re: [PERFORM] Is There Any Way ....

g systems, and the itch just isn't bad enough to scratch yet. They remain unconvinced that the gain in performance, would be worth the cost of maintaining this extra complexity in the code base. If you believe the case can be made, it is up to you to make it. Cheers! mar

Re: [HACKERS] [PERFORM] A Better External Sort?

s time spent in glibc routines. Do you have a reference for this? I believe this statement to be 100% false. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._.

Re: [HACKERS] [PERFORM] A Better External Sort?

out dd if=/dev/zero of=/dev/zero bs=1000 count=1 0.01s user 0.02s system 140% cpu 0.021 total At least some of this gets into the very in-depth discussions as to whether kernel threads, or user threads, are more efficient. Depending on the application, user threads can switch many time

Re: [PERFORM] count(*) using index scan in "query often, update rarely" environment

your counting query was still running. I don't see this being different from count(*) as it is today. Updating a count column is certainly clever. If using a trigger, perhaps it would allow the equivalent of: select count(*) from table for update; :-) Cheers, mark (not that this is ne

Re: [PERFORM] Best way to get all different values in a column

reated each time > TABLE is updated. I've found a variant on 6 to work well for this problem domain. Why not insert into the separate table, when you insert into the table? Either as a trigger, or in your application. Cheers, mark -- [EMAIL PROTECTED] / [

[PERFORM] prepared transactions that persist across sessions?

ssibly even longer? I'm thinking I need some way of defined a server side query, that takes arguments, that will infrequently prepare the query, such that the majority of the time that it is executed, it will not have to choose a query plan. Am I missing something obvious? :-) Thanks, m

Re: [PERFORM] 8.x index insert performance

effect? Which is it? :-) Thanks, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__

Re: [PERFORM] 8.x index insert performance

stored. I expect that the seqscan is used if the null values are not selective enough, the same as any other value that isn't selective enough. Now we can both have a little more confidence! :-) Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTE

Re: [PERFORM] WAL sync behaviour

, that is my understanding, anyways, and this is why I would not use ext2 for the database, even if it was claimed that fsync() was used. For WAL, with pre-allocated zero blocks? Sure. Ext2... :-) mark -- [EMAIL PROT

Re: [PERFORM] Opinions on Raid

main system data on RAID 1+0. The main system on RAID 1. A larger build partition on RAID 0. For a crappy server in my basement, I've very happy with my software RAID performance now. :-) Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]

Re: [PERFORM] Performance of count(*)

EQUENCE objects, as there could as the rows are [key, sequence, data], with thousands or more keys) Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . ._

Re: [PERFORM] SCSI vs SATA

counts. Is the opinion being expressed that manufacturers who have decided to move to SATAII are not designing for the enterprise market yes? I find myself doubting this... Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTEC

Re: [PERFORM] SCSI vs SATA

fail. Paying double price for hardware, with a hope that they will not fail, may not be a good strategy. I don't have a conclusion here - only things to consider. Cheers, mark -- [EMAIL PROTEC

Re: [PERFORM] LIKE search and performance

On Thu, May 24, 2007 at 02:02:40PM -0700, Mark Lewis wrote: > PG could scan the index looking for matches first and only load the > actual rows if it found a match, but that could only be a possible win > if there were very few matches, because the difference in cost between a > ful

Re: [PERFORM] LIKE search and performance

triction. Not allowing best performance in a common situation vs not allowing worst performance in a not-so-common situation. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PR

Re: [PERFORM] LIKE search and performance

ed. I question whether a like '%bar%' should be considered a high selectivity query in the general case. I question whether a worst case should be assumed. Perhaps I question too much? :-) Cheers, mark -- [EMAIL PROTECTED]

Re: [PERFORM] ECC RAM really needed?

any case - the word 'cheap' is significant in the above paragraph. non-ECC RAM should be considered 'cheap' memory. It will work fine most of the time and most people will never notice a problem. Do you want to be the one pers

Re: [PERFORM] setting up raid10 with more than 4 drives

ts both RAID-style storage *and* journal-style file system. I imagine consistency and ordering is handled through journalling. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._

Re: [PERFORM] setting up raid10 with more than 4 drives

ive to load patterns. This suggests a trial and error / benchmarking requirement to determine the optimal stripe size for your use. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .

Re: [PERFORM] Autodetect of software RAID1+0 fails

dm has the flexibility that you don't need an even number of disks. As I don't intend to add disks to my array - the RAID10 as a single layer, with potentially better intelligence in terms of performance, appeals to me. They both worked for me - but I am sticking with the singl

Re: [PERFORM] Question about SQL performance

erformance problem? Or are you trying to avoid issues that you are not sure if they exist or not? :-) Prepared queries are going to improve performance due to being able to execute multiple queries without communicating back to the client. Especially for short queries, network latency c

Re: [PERFORM] LIKE search and performance

er thread can't be doing that. I believe PostgreSQL already considers using the index for "starts with", so this wasn't part of the discussion for me. Sorry that this wasn't clear. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTE

Re: [OT] Re: [PERFORM] How much ram is too much

nd the community > version were the same. I think Microsoft > will avoid reusing its versions when year 2095 comes. :-) He should have written RHEL 4.0. RH 4.0 is long enough ago, though, that I think few would assume it meant the much older release. You'll find a similar thing with

[PERFORM] Held idle connections vs use of a Pooler

he in-house stuff to make use of a connection pooler ? thank you for your time. ..: mark -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

[PERFORM] cleanup on pg_ system tables?

neither seem to be clearing these out, tried a cluster and it won't let me. I am viewing the problem wrong? is there anything I can do while the DB is online ? do I need to clean up other things first ? thanks, ..: Mark -[ RECORD 1 ]+ schemaname | pg_ca

Re: [PERFORM] Using Between

on't help many applications of PG but there are a few outlying instances where this change can help a little bit. I am sure someone will step in and tell you it is a bad idea - AND they will probably have perfectly valid reasons for why it is, so you will need to consider the ramifications..

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

Could this be an interesting test use of https://www.fossexperts.com/ ? 'Community' driven proposal - multiple people / orgs agree to pay various portions? Maybe with multiple funders a reasonable target fund amount could be reached. Just throwing around ideas here. Mark ---

Re: [PERFORM] Hardware recommendations

any official pricing yet, but I would suspect it would be in the same ballpark. I am currently begging to get some for eval. I will let everyone know if I swing that and can post numbers. -mark -- 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] Hardware recommendations

it configured at 1024 checkpoint_segments, 5min timeout,0.9 > compiostat -x 5letion_target I would consider bumping that checkpoint timeout duration to a bit longer and see if that helps any if you are still looking for knobs to fiddle with. YMMV. -Mark -- Sent via pgsql-performanc

Re: [PERFORM] Migrating to Postgresql and new hardware

ompare in > performance running Postgresql? > How would the hardware usage of Postgresql compare to MySqls? I won't hazard a guess on the performance difference between PG w/ Fsync ON and MySQL running with MyISAM. If you can get your OS and PG tuned you should be able to have a

Re: [PERFORM] Queries becoming slow under heavy load

> -Original Message- > From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance- > ow...@postgresql.org] On Behalf Of Ivan Voras > Sent: Wednesday, January 26, 2011 6:25 AM > To: pgsql-performance@postgresql.org > Subject: Re: [PERFORM] Queries becoming slow under heavy load

Re: [PERFORM] Xeon twice the performance of opteron

> -Original Message- > From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance- > ow...@postgresql.org] On Behalf Of Jeff > Sent: Thursday, March 17, 2011 9:14 AM > To: pgsql-performance@postgresql.org > Cc: Brian Ristuccia > Subject: [PERFORM] Xeon twice the performance of

Re: [PERFORM] Select in subselect vs select = any array

; > For example: >select * from nodes where node_id in ( 1, 2, 3 . ) > What does "large" number of primary keys mean ? I have seen some "odd" things happen when I passed, carelessly, tens of thousands of items to an in list for a generated query, but I don&

Re: [PERFORM] Suspending SELECTs

or the buck. I'm thinking along the lines of materialized views, for queries executed more than a dozen times in a short length of time... :-) In the mean time, I successfully use LIMIT and OFFSET without such an optimization, and things have been fine for me. Cheers, mark

Re: [PERFORM] Suspending SELECTs

ly 'persistent state cursors' or 'import/export cursor state' implementation. People would automatically benefit, without changing their applications. Cheers, mark -- [EMAIL

Re: [PERFORM] Suspending SELECTs

On Wed, Jan 18, 2006 at 03:41:57PM +, Harry Jackson wrote: > There are various reason why google might want to limit the search > result returned ie to encourage people to narrow their search. Prevent > screen scrapers from hitting them really hard blah blah. Perhaps less > than 0.0001% of

Re: [PERFORM] LIKE query on indexes

ondition is from start of the field, query planner should use > index to find such elements but explain command shows me it will do a > sequential scan. > is this lack of a feature or i am wrong somewhere? Is the query fast enough? How big is your table? What does explain analyze

Re: [PERFORM] Large (8M) cache vs. dual-core CPUs

and it depends on the workload. X2 sounds like biggotry against Intel... :-) Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood

Re: [PERFORM] Large (8M) cache vs. dual-core CPUs

. It is *not* 2X though. Anybody who claims this is being highly selective about which benchmarks they consider. One article is nothing. There is a lot of hype these days. AMD is winning the elite market, which means that they are able to continue to sell high. Intel, losing this market, is cut

Re: [PERFORM] Large (8M) cache vs. dual-core CPUs

Especially now that Intel is dropping it's prices due to overstock. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ |

Re: [PERFORM] Large (8M) cache vs. dual-core CPUs

It's why Opteron with RAID kicks ass over HyperTransport. > All of the above comments about the relative performance of > different RAM types become insignificant when performance is gated > by the HD subsystem. Yes. Luckily - we don't all have Terrabyte d

Re: [PERFORM] Large (8M) cache vs. dual-core CPUs

#x27;ve actually tried a very large, or thread intensive PostgreSQL db on both, I probably shouldn't doubt the work of others too much. :-) Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] _

Re: [PERFORM] 64-bit vs 32-bit performance ... backwards?

ok. Within registers, 64-bit should be equal speed to 32-bit. Outside the registers, it would make sense to only deal with the lower 32-bits where 32-bits is all that is required. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED

Re: [PERFORM] Postgresql Performance on an HP DL385 and

the indirect blocks to be updated without the data underneath, allowing for blocks to point to random data, or worse, previous apparently sane data (especially if the data is from a drive only used for xlog - the chance is high that a block might look partially valid?). So, I'm sticking with

Re: [PERFORM] Postgresql Performance on an HP DL385 and

ta journalling > filesystem is to save the fsck time when you come up. On a little > partition like xlog, that's not an issue. fsck isn't only about time to fix. fsck is needed, because the file system is broken. If the file system is broken, how can you guarantee data has not be

Re: [PERFORM] Postgresql Performance on an HP DL385 and

+ postgresql xlog has not been confirmed to me as reliable. Telling me that journalling is misunderstood doesn't prove to me that you understand it. I don't mean to be offensive, but I won't accept what you say, as it does

Re: [PERFORM] Postgresql Performance on an HP DL385 and

or not, fsck or not. It is safer than no postgresql xlog - but there exists windows, however small, where the file system can be corrupted. The need for fsck is due to this problem. If fsck needs to do anything at all, other than replay a journal, the file system is broken. Cheers, mar

Re: [PERFORM] Postgresql Performance on an HP DL385 and

structures change as a result of any writes that PostgreSQL does. If no file system structures change, then I take everything back as uninformed. Please confirm whichever. :-) Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]

Re: [PERFORM] Postgresql Performance on an HP DL385 and

cept what you say, as it does > >not make sense with my understanding of how file systems work. :-) > I'm not getting paid to convince you of anything. Just getting you to back up your claim a bit... As I said, no intent to offend. I learned from it. T

[PERFORM] Q: Performance of join vs embedded query for simple queries?

gt; 0.850 ms. Timings at these resolutions are not so reliable. :-) I think this means that the planner takes longer to figure out what to do about the join, and that my writing the select out as an embedded select reduces the effort required by the planner. This makes sense to me, except t

Re: [PERFORM] Q: Performance of join vs embedded query for simple queries?

, or is this a fundamentally difficult thing to get right in the general case? I did the elimination in my head, which is why I considered the plans to be the same. Can the planner do it? Sub-millisecond planning/execution for simple queries on moderate hardware seem

Re: [PERFORM] Q: Performance of join vs embedded query for simple queries?

otal runtime: 19.568 ms (7 rows) Time: 21.449 ms I guess the case isn't as simple as I thought. It would need to recognize that the specification of both the 'type' and the 'uid' are static, and unique, therefore the argument to the IN, or

Re: [PERFORM] Large tables (was: RAID 0 not as fast as expected)

is parameter is left at the default of 4, indexes will often > be used inappropriately. Does a tool exist yet to time this for a particular configuration? Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [

Re: [PERFORM] Large tables (was: RAID 0 not as fast as

that the page is less useful than all other pages currently in memory. This is what the call really means. It means, "There is no value to keeping this page in memory". Perhaps certain PostgreSQL loads fit this pattern. None of my uses fit this pattern, and I have trouble believing t

Re: [PERFORM] Opteron vs. Xeon "benchmark"

sn't crashing down any time soon. Perhaps they became a little lazy, and made a few mistakes. AMD is forcing them to clean up. May the competition continue... :-) Cheers, mark -- [EMAIL PROTECTED] / [EMA

Re: [PERFORM] Hints proposal

g filled with a desire to try out some of their ideas. You need to brain wash them... :-) Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .

Re: [PERFORM] Optimization of this SQL sentence

use varchar instead of text, but have since softened, as the number of times it has ever actually saved me is zero, and the number of times it has screwed me up (picking too small of a limit too early) has been a few. It's kind of like pre-optimization before there is a problem. Sometim

OT: TCL vs Perl Re: [PERFORM] commit so slow program looks frozen

x is deceivingly comparable to other well known languages, and for the longest time, it was much faster than TCL to write (especially when using regular expressions) and faster to run. Did TCL get treated unfairly as a result? It's a language. Who cares! :-)

Re: [PERFORM] MVCC & indexes?

servative. They only guarantee to return at least as much data as you should see. They cannot be used to limit what you see to only as much as you should see. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]

Re: [PERFORM] Linux: more cores = less concurrency.

> -Original Message- > From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance- > ow...@postgresql.org] On Behalf Of Scott Marlowe > Sent: Monday, April 11, 2011 1:29 PM > To: Glyn Astill > Cc: Kevin Grittner; Joshua D. Drake; pgsql-performance@postgresql.org > Subject: Re:

Re: [PERFORM] Linux: more cores = less concurrency.

> -Original Message- > From: Scott Marlowe [mailto:scott.marl...@gmail.com] > Sent: Monday, April 11, 2011 6:18 PM > To: mark > Cc: Glyn Astill; Kevin Grittner; Joshua D. Drake; pgsql- > performa...@postgresql.org > Subject: Re: [PERFORM] Linux: more cores = less con

[PERFORM] rant ? check the BBWC

So sometime along yellow brick firmware road HP changed (and maybe your vendor did too) the output of what happens when the write cache is off due to failed batteries attached to the card/cache. (and no they don't always beep with a self test in case someone happens to be walking near your cage, an

[PERFORM] Query improvement

Hi I have 3 tables page - revision - pagecontent CREATE TABLE mediawiki.page ( page_id serial NOT NULL, page_namespace smallint NOT NULL, page_title text NOT NULL, page_restrictions text, page_counter bigint NOT NULL DEFAULT 0, page_is_redirect smallint NOT NULL DEFAULT 0, page_is_n

Re: [PERFORM] Query improvement

Here is EXPLAIN ANALYZE: "Limit (cost=136568.00..136568.25 rows=100 width=185) (actual time=1952.174..1952.215 rows=100 loops=1)" " -> Sort (cost=136568.00..137152.26 rows=233703 width=185) (actual time=1952.172..1952.188 rows=100 loops=1)" "Sort Key: ((ts_rank(pc.textvector, to_tsquer

Re: [PERFORM] Query improvement

Thanks for replies. Finally I have used UNION and JOINS, which helped. Mainly the UNION helped a lot. Now the query takes 1sec max. Thanks a lot. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Query-improvement-tp4362578p4378163.html Sent from the PostgreSQL - performan

Re: [PERFORM] Query improvement

Thanks for reply both UNION and JOINS helped. Mainly the UNION helped a lot. Now the query takes 1sec max. Thanks a lot. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Query-improvement-tp4362578p4378157.html Sent from the PostgreSQL - performance mailing list archive a

Re: [PERFORM] Query improvement

Thanks a lot for reply. Finally I have used UNION, but thanks for your help. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Query-improvement-tp4362578p4378160.html Sent from the PostgreSQL - performance mailing list archive at Nabble.com. -- Sent via pgsql-performance

Re: [PERFORM] CLUSTER versus a dedicated table

You will need to post at lot more specific info if you want more specific help. The guide to reporting slow queries or guide to reporting problems and start gathering specific information and then post back to the list. -Mark > > -- > Sent via pgsql-performance mailing list (pgsql- &g

[PERFORM] not exits slow compared to not in. (nested loops killing me)

willing to try stuff for people as I can run things on a VM for days and it is no big deal. I can't do that on production machines. thoughts ? ideas ? -Mark -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.pos

Re: [PERFORM] not exits slow compared to not in. (nested loops killing me)

> -Original Message- > From: Craig Ringer [mailto:cr...@postnewspapers.com.au] > Sent: Monday, June 06, 2011 5:08 PM > To: mark > Cc: pgsql-performance@postgresql.org > Subject: Re: [PERFORM] not exits slow compared to not in. (nested loops > killing me) > > O

[PERFORM] benchmark woes and XFS options

Hello PG perf junkies, Sorry this may get a little long winded. Apologies if the formatting gets trashed. Also apologies if this double posts. (I originally set it yesterday with the wrong account and the message is stalled - so my bad there) if someone is a mod and it's still in the wait queue

Re: [PERFORM] benchmark woes and XFS options

> -Original Message- > From: Greg Smith [mailto:g...@2ndquadrant.com] > Sent: Monday, August 08, 2011 9:42 PM > To: mark > Cc: pgsql-performance@postgresql.org > Subject: Re: [PERFORM] benchmark woes and XFS options > > I think your notion that you have an HP CC

[PERFORM] XFS options and benchmark woes

Hello PG perf junkies, Sorry this may get a little long winded. Apologies if the formatting gets trashed. Background: I have been setting up some new servers for PG and I am getting some odd numbers with zcav, I am hoping a second set of eyes here can point me in the right direction. (other

Re: [PERFORM] XFS options and benchmark woes

> -Original Message- > From: mark [mailto:m...@sm-a.net] > Sent: Monday, August 08, 2011 12:15 AM > To: 'pgsql-performance@postgresql.org' > Subject: XFS options and benchmark woes > > Hello PG perf junkies, > > > Sorry this may get a little

Re: [PERFORM] Raid 5 vs Raid 10 Benchmarks Using bonnie++

unt options. With a battery-backed write cache, you'd want to > use "nobarrier" for example; if you didn't do that, that can crush > output rates. > To clarify maybe for those new at using non-default mount options. With XFS the mount option is nobarrier. With e

Re: [PERFORM] RAID Controller (HP P400) beat by SW-RAID?

health. (I don't recall the official name, but new versions if hpacucli might not play well with old versions of hp health. Its HP so they have a new version about every month for firmware and their cli utility... that’s HP for us. Anyways that is my fast input. Best of luck, -Mark --

Re: [PERFORM] pg9 replication over WAN ?

that was really a change in the setting or a fix to our load balancers that fixed an issue I was seeing. Overall I am extremely pleased with streaming replication + read only hot standby. -Mark > > -- > Sent via pgsql-performance mailing list (pgsql- > performa...@po

[PERFORM] Deferred constraints performance impact ?

r are the two not comparable in terms of impact from what is tracked and then checked. Anyways, just looking for feedback if anyone has any. -Mark -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mai

Re: [PERFORM] Delete query takes exorbitant amount of time

s already committed the improvement, so I'm in Tom's fan club today. I imported my test dataset and was almost immediately able to track down the cause of my performance problem. Thanks! Mark Lewis ---(end of broadcast)-

[PERFORM] Correcting Hash Join Estimates

ins about 10,000 rows. All tables have indexes on their foreign keys. Thanks! Mark ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Re: [PERFORM] Correcting Hash Join Estimates

omplainers that it's as good as it's going to get (barring a major hardware upgrade...). Thanks! Mark ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [PERFORM] [NOVICE] Many connections lingering

broker, which could then implement connection pooling. -- Mark Lewis On Tue, 2005-04-12 at 22:09, Slavisa Garic wrote: > This is a serious problem for me as there are multiple users using our > software on our server and I would want to avoid having connections > open for a long time. In the

[PERFORM] PLM pulling from CVS nightly for testing in STP

STP http://www.osdl.org/stp/ PLM http://www.osdl.org/plm-cgi/plm Mark ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] PLM pulling from CVS nightly for testing in STP

On Wed, Apr 13, 2005 at 11:35:36AM -0700, Josh Berkus wrote: > Mark, > > > Just wanted everyone to know what we're pulling CVS HEAD nightly so it > > can be tested in STP now. Let me know if you have any questions. > > Way cool.How do I find the PLM number? Ho

Re: [PERFORM] [HACKERS] PLM pulling from CVS nightly for testing in STP

I have dbt-2 tests automatically running against each pull from CVS and have started to automatically compile results here: http://developer.osdl.org/markw/postgrescvs/ I did start with a bit of a minimalistic approach, so I'm open for any comments, feedback, etc.

Re: [PERFORM] Kernel Resources and max_connections

ernel tunable is a bit of a downer). cheers Mark ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] Kernel Resources and max_connections

Chris Hebrard wrote: I set the values in etc/sysctl.conf: # $FreeBSD: src/etc/sysctl.conf,v 1.1.2.3 2002/04/15 00:44:13 dougb Exp $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Added by IMP

Re: [PERFORM] [GENERAL] "Hash index" vs. "b-tree index" (PostgreSQL

If the original paper was published in 1984, then it's been more than 20 years. Any potential patents would already have expired, no? -- Mark Lewis On Tue, 2005-05-10 at 14:35, Mischa Sandberg wrote: > Quoting "Jim C. Nasby" <[EMAIL PROTECTED]>: > > > W

[PERFORM] Select performance vs. mssql

deas to try? Thanks much, Mark __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---(end of broadcast)--- TIP 3: if posting/reading throu

Re: [PERFORM] Select performance vs. mssql

k 24 seconds after fresh reboot, next execution was 11, and execution without explain analyze was 6.7 seconds) MSSQL Machine: That "Explain Analyze" command doesn't work for MSSQL, but I did view the Query plan. 97% of it was "Scanning a particular range of rows from a nonclust

Re: [PERFORM] Select performance vs. mssql

ng one query faster, it would make everything else faster/more scalable as the server load is so much less. Thanks again, Mark __ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/

Re: [PERFORM] Select performance vs. mssql

something like this with (nolock) i.e. select count(*) from customers (nolock) where name like 'Mark%' Regardless, I'm very impressed with PostgreSQL and I think we're moving ahead with it. Mark --- Bruno Wolff III <[EMAIL PROTECTED]> wrote: > On Tue, May 24, 2005

Re: [PERFORM] tuning

or v (cost=0.00..20.00 rows=1000 width=54) (actual time=0.060..3.653 rows=2797 loops=1) Total runtime: 39094.713 ms (10 rows) I guess the relation 'test' is a copy of product (?) Cheers Mark ---(end of broadcast)--- TIP 9: the

Re: [PERFORM] postgresql-8.0.1 performance tuning

4kb. Google around: This is somewhat confusing : kernel.shmmax is in bytes (max single segment size) kernel.shmall is in (4k) pages (max system wide allocated segment pages) cheers Mark ---(end of broadcast)--- TIP 9: the planner will

  1   2   3   4   5   6   7   8   9   10   >