Re: [PERFORM] Optimizing a VIEW

and history.customer_data - it will run much faster. Matthew -- Here we go - the Fairy Godmother redundancy proof. -- Computer Science Lecturer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http

Re: [PERFORM] Slow query with a lot of data

ORDER BY domain and have it say Index scan instead of Seq Scan followed by disc sort). Matthew -- Patron: I am looking for a globe of the earth. Librarian: We have a table-top model over here. Patron: No, that's not good enough. Don't you have a life-size? Librarian: (pause) Yes, but it's in use

Re: [PERFORM] Slow query with a lot of data

for all users a little. Matthew -- For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your

Re: [PERFORM] Slow query with a lot of data

on result a Matthew -- Vacuums are nothings. We only mention them to let them know we know they're there. -- 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] Filesystem benchmarking for pg 8.3.3 server

is that in the past we only had a flush everything command whereas now we have a flush everything before the barrier before everything after the barrier command. Matthew -- To err is human; to really louse things up requires root privileges. -- Alexander Pope, slightly paraphrased

Re: [PERFORM] Database size Vs performance degradation

growing more than it needs to. However, a vacuum full is required to actually reduce the size of the table from 7.5G to 2.7G if that hasn't been done on the production system already. Matthew -- It's one of those irregular verbs - I have an independent mind, You are an eccentric, He is round

Re: [PERFORM] Database size Vs performance degradation

vacuuming more agressively is going to be your best win at the moment. Matthew -- Patron: I am looking for a globe of the earth. Librarian: We have a table-top model over here. Patron: No, that's not good enough. Don't you have a life-size? Librarian: (pause) Yes, but it's in use right now. -- Sent

Re: [PERFORM] how does pg handle concurrent queries and same queries

. Matthew -- Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent. -- 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] Planner should use index on a LIKE 'foo%' query

on earth is wrong with writing it like this? SELECT COUNT(*) FROM (SELECT DISTINCT result.url FROM result, item WHERE item.shorturl = result.url) AS a That should do a fairly sensible join plan. There's no point in using fancy IN or EXISTS syntax when a normal join will do. Matthew -- I

Re: [PERFORM] Planner should use index on a LIKE 'foo%' query

, and ANALYSE, then this query should run as a merge join, and be pretty quick. However, this is always going to be a long-running query, because it accesses at least one whole table scan of a large table. Matthew -- Finger to spiritual emptiness underlying everything. -- How a foreign C manual

Re: [PERFORM] Planner should use index on a LIKE 'foo%' query

will contain more results, but it will only be run once, rather than multiple times. This is effectively forcing a hash join (kind of). Whereas if you rewrite the query as I demonstrated earlier, then you allow Postgres to make its own choice about which join algorithm will work best. Matthew

Re: [PERFORM] Hardware vs Software RAID

figures quoted for many other devices, but of course unless they publish the block size they used for the random speed tests, the figures are completely useless. Matthew -- sed -e '/^[when][coders]/!d;/^...[discover].$/d;/^..[real].[code]$/!d ' `locate dict/words` -- Sent via pgsql-performance

Re: [PERFORM] Hardware vs Software RAID

writes was no longer true these days? Matthew -- I work for an investment bank. I have dealt with code written by stock exchanges. I have seen how the computer systems that store your money are run. If I ever make a fortune, I will store it in gold bullion under my bed

Re: [PERFORM] Hardware suggestions for high performance 8.3

. I'd get ten identical discs and put them in a single array, probably RAID 10. Also, do you really need 6*750GB for OS and transaction logs? How big can they be? However, the most important factor is that you get a good BBU cache. Matthew -- I don't want the truth. I want something I can tell

Re: [PERFORM] Hardware suggestions for high performance 8.3

a cabinett. Or you could just get 10 large SATA drives. To be honest, the performance difference is not large, especially if you ensure the database data is held compactly on the discs, so the seeks are small. Matthew -- It's one of those irregular verbs - I have an independent mind, You

Re: [PERFORM] Hardware vs Software RAID

a hefty price tag. Matthew -- $ rm core Segmentation Fault (core dumped) -- 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 vs Software RAID

in performance when writing small random blocks. But what's it actually like, and is it reliable? Matthew -- Terrorists evolve but security is intelligently designed? -- Jake von Slatt -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your

Re: [PERFORM] Tsearch2 Initial Search Speed

an even smaller table. However, are email_ids all that you want from the query? Matthew -- Okay, I'm weird! But I'm saving up to be eccentric. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [PERFORM] Tsearch2 Initial Search Speed

. Matthew -- For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [PERFORM] Tsearch2 Initial Search Speed

. Matthew -- Lord grant me patience, and I want it NOW! -- 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] Tsearch2 Initial Search Speed

the actual rows. Of course, it only needs to bother looking where the index points, and that is the benefit of an index. Matthew -- I've run DOOM more in the last few days than I have the last few months. I just love debugging ;-) -- Linus Torvalds -- Sent via pgsql-performance mailing list

Re: [PERFORM] Tsearch2 Initial Search Speed

information, including whether the row is visible in your current transaction (concurrency control complicates it all). Just having a page number isn't much use to you! Matthew -- First law of computing: Anything can go wro sig: Segmentation fault. core dumped. -- Sent via pgsql-performance

Re: [PERFORM] Migration Articles.. ???

into a new database. RTFM on pg_dump, especially the -t and -T options. Matthew -- All of this sounds mildly turgid and messy and confusing... but what the heck. That's what programming's all about, really -- Computer Science Lecturer -- Sent via pgsql

Re: [PERFORM] Which hardware ?

isn't going to be such a problem, and given that, I'd disagree with Andrew and say as long as you have plenty of RAM, Java can play well with a database on the same box. Depends what it is doing, of course. Matthew -- To be or not to be -- Shakespeare To do

Re: [PERFORM] Tsearch2 Initial Search Speed

can't unmount hot, you'll need to reboot. Not true - on recent Linux kernels, you can drop the OS cache by running echo 1 /proc/sys/vm/drop_caches as root. You'll still need to restart Postgres to drop its cache too. Matthew -- Richards' Laws of Data Security: 1. Don't buy a computer. 2. If you

Re: [PERFORM] insert/update tps slow with indices on table 1M rows

by the number of simultaneous connections. Matthew -- Contrary to popular belief, Unix is user friendly. It just happens to be very selective about who its friends are. -- Kyle Hearn -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes

Re: [PERFORM] backend pid changing

a variable twice. It seems you have client-side error recovery on the initial check, but not on the second check. The solution is to eliminate the first check, and implement proper error recovery on the second check, so that the client can just get a new hash and try again. Matthew -- It's one

Re: [PERFORM] Outer joins and equivalence

On Tue, 27 May 2008, Simon Riggs wrote: I do recognise that we would *not* be able to deduce this form of SQL A JOIN B ON (a.id = c.id) LEFT JOIN C ON (b.id = c.id) Surely that would not be valid SQL? Matthew -- Psychotics are consistently inconsistent. The essence of sanity

Re: [PERFORM] Index creation time and distribution

performance. Matthew -- First law of computing: Anything can go wro sig: Segmentation fault. core dumped. -- 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] I/O on select count(*)

to avoid is all the rest of the transactions waiting for the new pg_clog page. The trick is to generate the new page early, outside any locks on existing pages. It doesn't necessarily need to be done by a daemon thread at all. Matthew -- I'm NOT paranoid! Which of my enemies told you

Re: [PERFORM] which ext3 fs type should I use for postgresql

into ext3 instead of ext2 - many people say that for Postgres you shouldn't do this, as ext2 is faster. Matthew -- The surest protection against temptation is cowardice. -- Mark Twain -- Sent via pgsql-performance mailing list (pgsql-performance

Re: [PERFORM] which ext3 fs type should I use for postgresql

), this 5% that only root can use also serves as a buffer against that as well. It makes sense to me that the usage pattern of Postgres would be much less susceptible to causing fragmentation than normal filesystem usage. Has anyone actually tested this and found out? Matthew -- Isn't Microsoft

Re: [PERFORM] I/O on select count(*)

in the same 128MB bracket, you'll hit the disc read-ahead buffer for the hints. On balance, to me it still seems like a good option. Matthew -- Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer -- Sent via pgsql-performance mailing list (pgsql

Re: [PERFORM] I/O on select count(*)

the changes to the index together. This is likely to speed up index writes quite a bit, and also allow you to effectively vacuum aborted tuples before they get written to the disc. Matthew -- Vacuums are nothings. We only mention them to let them know we know they're there. -- Sent via pgsql

Re: [PERFORM] I/O on select count(*)

checkpoint. Keeping data in memory for the length of the transaction is doomed to failure, because there is no bound on its size, so bulk loads are still going to miss out on hint optimisation. Matthew -- for a in past present future; do for b in clients employers associates relatives

Re: [PERFORM] which ext3 fs type should I use for postgresql

, the not enough space to delete file, delete some files and try again problem. Anyway, that isn't relevant to the reserved percentage, as that will happen whether or not the filesystem is 5% smaller. Matthew -- Let's say I go into a field and I hear baa baa baa. Now, how do I work out whether that was baa

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

of degradation with cfq - I guess it's worse the bigger the disc subsystem you have. Matthew -- Matthew: That's one of things about Cambridge - all the roads keep changing names as you walk along them, like Hills Road in particular. Sagar: Yes, Sidney Street is a bit like that too. Matthew

Re: [PERFORM] multiple joins + Order by + LIMIT query performance issue

; The subselect will be planned without awareness of the LIMIT, so you should get a plan using a sort rather than one that bets on the LIMIT being reached quickly. Surely if that's the case, that in itself is a bug? Apart from being useful, I mean. Matthew -- Television is a medium because it is neither

Re: [PERFORM] two memory-consuming postgres processes

* FROM original, derived, derived2, ... WHERE original.pk = derived.pk ... That should be a merge join, which should run really quickly, and you can then create all the indexes you want on it. Matthew -- When I first started working with sendmail, I was convinced that the cf file had been

Re: [PERFORM] Optimizer's issue

the relevant join plans to see how long Postgres takes with your desired plan? When you have millions of rows, the algorithm matters a lot more. Matthew -- Richards' Laws of Data Security: 1. Don't buy a computer. 2. If you must buy a computer, don't turn it on. -- Sent via pgsql-performance

Re: [PERFORM] Question about disk IO an index use and seeking advice

myself though. Matthew -- Me... a skeptic? I trust you have proof? -- 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] Group by more efficient than distinct?

, it doesn't need to look up anything on disc for that branch of the join again, and it has a rapid in-memory lookup for each row. Matthew -- X's book explains this very well, but, poor bloke, he did the Cambridge Maths Tripos... -- Computer Science Lecturer -- Sent via

Re: [PERFORM] Group by more efficient than distinct?

an entry for each group in the hash table, and does not store the actual rows. For that situation, you can have a bazillion individual rows, but only a small number of distinct groups. Matthew -- First law of computing: Anything can go wro sig: Segmentation fault. core dumped. -- Sent via

Re: [PERFORM] Strange behavior: pgbench and new Linux kernels

. So what happens if you run pgbench on a separate machine to the server? Does the problem still exist in that case? Matthew -- X's book explains this very well, but, poor bloke, he did the Cambridge Maths Tripos... -- Computer Science Lecturer -- Sent via pgsql

Re: [PERFORM] Strange behavior: pgbench and new Linux kernels

on and try increasing that value, and see if that fixes the problem. Alternatively, use sched_setscheduler to set SCHED_BATCH, which should increase the timeslice (a Linux-only option). Matthew -- Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent

Re: [PERFORM] Strange behavior: pgbench and new Linux kernels

=2 The last message in the thread says that 2.6.25-rc6 has the problem nailed. That was a month ago. So I guess, upgrade to 2.6.25, which was released today. Matthew -- Prove to thyself that all circuits that radiateth and upon which thou worketh are grounded, lest they lift thee to high

Re: [PERFORM] Performance increase with elevator=deadline

. it also seems changing elevators on the fly works fine (echo schedulername /sys/block/.../queue/scheduler I admit I sat there flipping back and forth going disk go fast.. disk go slow.. disk go fast... :) Oh Homer Simpson, your legacy lives on. Matthew -- I suppose some of you have done

Re: [PERFORM] large tables and simple = constant queries using indexes

this, for bitmap index scans, by using fadvise(), so a single thread can utilise multiple discs in a RAID array. Matthew -- Prolog doesn't have enough parentheses. -- Computer Science Lecturer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your

Re: [PERFORM] EXPLAIN detail

. Matthew -- There once was a limerick .sig that really was not very big It was going quite fine Till it reached the fourth line -- 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] Forcing more agressive index scans for BITMAP AND

be best to use multicolumn indexes. You would just need to create an index for each of the combinations that you are likely to use. Matthew -- To err is human; to really louse things up requires root privileges. -- Alexander Pope, slightly paraphrased -- Sent via pgsql-performance

Re: [PERFORM] bulk insert performance problem

a table in the same transaction as you load data into it. So, if you have a database dump, load it in using psql -1, which wraps the entire operation in a single transaction. Of course, a COPY dump will load a lot faster than a INSERT dump. Matthew -- What goes up must come down. Ask any

Re: [PERFORM] Forcing more agressive index scans for BITMAP AND

On Mon, 7 Apr 2008, Ow Mun Heng wrote: just wondering if there's a special tweak i can do to force more usage of indexes to do BITMAP ands? There's no need to post this again. You have already had a couple of useful answers. Matthew -- All of this sounds mildly turgid and messy

Re: [PERFORM] Severe performance problems for simple query

at some point soon too. Matthew -- I wouldn't be so paranoid if you weren't all out to get me!! -- 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] Severe performance problems for simple query

by ipFrom, and LIMIT to the first result: SELECT blah FROM table_name WHERE ipFrom = 42 ORDER BY ipFrom DESC LIMIT 1 This should run *very* quickly. However, if any entries overlap at all then you will get incorrect results. Matthew -- I'm always interested when [cold callers] try to flog

Re: [PERFORM] Severe performance problems for simple query

is handed to the index at a time. So all the current R-tree implementations require that you generate an object containing the two values, like the box, and then index that. Something for 8.4? Matthew -- $ rm core Segmentation Fault (core dumped) -- Sent via pgsql-performance mailing list (pgsql

Re: [PERFORM] Forcing more agressive index scans for BITMAP AND

); It'll certainly be faster than building a bitmap for the contents of five separate indexes. Matthew -- -. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. ||X|||\ /|||X|||\ /|||X|||\ /|||X|||\ /|||X|||\ /|||X|||\ /||| |/ \|||X|||/ \|||X|||/ \|||X|||/ \|||X|||/ \|||X|||/ \|||X

Re: [PERFORM] Max shared_buffers

of ¿½postgreS shared_buffers and work_mem? that would be a Yes. Matthew -- I quite understand I'm doing algebra on the blackboard and the usual response is to throw objects... If you're going to freak out... wait until party time and invite me along -- Computer Science Lecturer

Re: [PERFORM] check performance parameters

that ? Assuming you have a vaguely unix/linux-ish type system, then use iostat. Matthew -- Reality is that which, when you stop believing in it, doesn't go away. -- Philip K. Dick -- Sent via pgsql-performance mailing list (pgsql-performance

Re: [PERFORM] Slow query or just Bad hardware?

. If you have lots of write traffic make sure you recluster every now and again. Experiment with that, and see if it helps. Matthew -- The only secure computer is one that's unplugged, locked in a safe, and buried 20 feet under the ground in a secret location...and i'm not even too sure about

Re: [PERFORM] what is the maximum number of rows in a table in postgresql 8.1

with an arawb (thousand million) or more rows without any significant performance problems. However, if you tell Postgres to read the entire table (like doing SELECT COUNT(*) FROM table), it will obviously take time. Matthew -- In the beginning was the word, and the word was unsigned, and the main

Re: [PERFORM] 1-/2-dimensional indexes for common columns, rationale?

, so foo1 could be viewed as redundant. I'd be interested in hearing from the Powers That Be whether foo2 is redundant too. It wasn't a while back. My impression is that foo3 isn't much more expensive to alter than foo1 - is that correct? Matthew -- Lord grant me patience, and I want it NOW

Re: [PERFORM] Planning hot/live backups?

Steve Poe wrote: The owners of the animal hospital where I work at want to consider live/hot backups through out the day so we're less likely to lose a whole day of transaction. We use Postgresql 8.0.15. We do 3AM backups, using pg_dumpall, to a file when there is very little activity. You

Re: [PERFORM] Planning hot/live backups?

Steve Poe wrote: At this point, I am just moving the pg_dumpall file to another server. Pardon my question: how would you 'ship the log files'? [ You should cc the mailing list so that everyone can benefit from the conversation. ] RTM:

Re: [PERFORM] Planner mis-estimation using nested loops followup

. Such cleverness would be very cool, but (I understand) a lot of work. It would hopefully solve this problem. Matthew -- Taking apron off And now you can say honestly that you have been to a lecture where you watched paint dry. - Computer Graphics Lecturer -- Sent via pgsql-performance mailing

Re: [PERFORM] count * performance issue

indexed_field IS NOT NULL For certain, qualified definitions of fast, sure. And certain, qualified definitions of accurate as well. Race condition? Matthew -- Television is a medium because it is neither rare nor well done. -- Fred Friendly -- Sent via pgsql-performance mailing list

Re: [PERFORM] Toast space grows

bloat. Matthew -- Now the reason people powdered their faces back then was to change the values s and n in this equation here. - Computer science lecturer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http

Re: [PERFORM] Toast space grows

. Matthew -- To err is human; to really louse things up requires root privileges. -- Alexander Pope, slightly paraphrased -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [PERFORM] Performance tuning on FreeBSD

on each rotation instead of just one. Matthew -- People who love sausages, respect the law, and work with IT standards shouldn't watch any of them being made. -- Peter Gutmann -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your Subscription

Re: [PERFORM] How to allocate 8 disks

an issue, and you can accept reinstalling the system if you lose a disc, then there's a third option: 8 discs RAID 0: Everything Matthew -- Heat is work, and work's a curse. All the heat in the universe, it's going to cool down, because it can't increase, then there'll be no more work, and there'll

Re: [PERFORM] How to allocate 8 disks

drives, so is slower. Whether this is true in reality is another matter, as all sorts of factors come in, not least how good your controller is at managing the arrangement. Matthew -- The only secure computer is one that's unplugged, locked in a safe, and buried 20 feet under the ground

Re: [PERFORM] 12 disks raid setup

for the cache, and then just putting then all in one RAID 10 lump. Matthew -- To be or not to be -- Shakespeare To do is to be -- Nietzsche To be is to do -- Sartre Do be do be do -- Sinatra ---(end of broadcast

Re: [PERFORM] Q on views and performance

because of the extra volume of data. Matthew -- [About NP-completeness] These are the problems that make efficient use of the Fairy Godmother.-- Computer Science Lecturer ---(end of broadcast)--- TIP 7: You can help support

Re: [PERFORM] Q on views and performance

the correlation for the index. Opinions? Matthew -- If you let your happiness depend upon how somebody else feels about you, now you have to control how somebody else feels about you. -- Abraham Hicks ---(end of broadcast)--- TIP 9: In versions below

Re: [PERFORM] Weird issue with planner choosing seq scan

. Matthew -- Failure is not an option. It comes bundled with your Microsoft product. -- Ferenc Mantfeld ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http

Re: [PERFORM] Q on views and performance

On Mon, 25 Feb 2008, Kynn Jones wrote: This is just GREAT!!! It fits the problem to a tee. It makes the queries quick then? Matthew -- The only secure computer is one that's unplugged, locked in a safe, and buried 20 feet under the ground in a secret location...and i'm not even too sure

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

there. After that I'd do a group by and count(*) on that table. Is this a good idea? That sounds like the fastest way to do it, certainly. Matthew -- We have always been quite clear that Win95 and Win98 are not the systems to use if you are in a hostile security environment. We absolutely do recognize

Re: [PERFORM] 7 hrs for a pg_restore?

CREATE INDEXes both trying to update the pg_class row, but I thought we'd fixed it. It was a while back, and that sounds like exactly the error it returned. It sounds like you have fixed it. Matthew -- Software suppliers are trying to make their software packages more 'user-friendly

Re: [PERFORM] Anyone using a SAN?

, and expensive. Matthew -- Nog: Look! They've made me into an ensign! O'Brien: I didn't know things were going so badly. Nog: Frightening, isn't it? ---(end of broadcast)--- TIP 4: Have you searched our list archives? http

Re: [PERFORM] 7 hrs for a pg_restore?

(say) a subsequent psql invocation. Which is exactly not what is wanted. It's even better than that. I don't see an export there, so it won't take effect at all! Matthew -- Failure is not an option. It comes bundled with your Microsoft product

Re: [PERFORM] Disable WAL completely

device? The too many writes wear it out argument is mostly not true nowadays anyway. Matthew -- Don't worry! The world can't end today because it's already tomorrow in Australia. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ

Re: [PERFORM] Query slows after offset of 100K

will improve the performance of the sort in the second case. Of course, what others have said about trying to avoid large offsets is good advice. You don't actually need a unique index, but it makes it simpler if you do. Matthew -- The early bird gets the worm. If you want something else

Re: [PERFORM] Small DB Server Advice

or it may be woefully inadequate, but this machine looks like a fairly good buy for the price. Matthew -- No trees were killed in the sending of this message. However a large number of electrons were terribly inconvenienced. ---(end of broadcast)--- TIP

Re: [PERFORM] Small DB Server Advice

. And it'll also pick up other write activity onthe system... Of course. My point was that 64MB should be quite sufficient if most accesses are reads. We have a few machines here with 2GB BBU caches as we do LOTS of writes - that sort of thing probably isn't necessary here. Matthew -- I

Re: [PERFORM] Benchmark Data requested --- pgloader CE design ideas

the same algorithm to work out where the boundary is, therefore they'll get the same result. No need to pass back information. Matthew -- There is something in the lecture course which may not have been visible so far, which is reality -- Computer Science Lecturer

Re: [PERFORM] Performance problems inside a stored procedure.

very much for your time. Regards Matthew Андрей Репко wrote: Hello Matthew, Monday, January 28, 2008, 2:02:26 PM, Вы писали: ML I have a query which runs pretty quick ( 0.82ms) but when I put it ML inside a stored procedure it takes 10 times as long (11.229ms). Is ML this what you would

Re: [PERFORM] Benchmark Data requested

On Tue, 5 Feb 2008, Richard Huxton wrote: In the case of a bulk upload to an empty table (or partition?) could you not optimise the WAL away? Argh. If I hadn't had to retype my email, I would have suggested that before you. ;) Matthew -- Unfortunately, university regulations probably

Re: [PERFORM] Benchmark Data requested

optimized and all the rest not. Why would you need to lock the table? Matthew -- Picard: I was just paid a visit from Q. Riker: Q! Any idea what he's up to? Picard: No. He said he wanted to be nice to me. Riker: I'll alert the crew. ---(end of broadcast

Re: [PERFORM] Benchmark Data requested

---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [PERFORM] Benchmark Data requested

be required. This would improve the performance of database restores and large writes which expand the table's data file. So, would it work? Matthew -- If pro is the opposite of con, what is the opposite of progress? ---(end of broadcast

Re: [PERFORM] Benchmark Data requested

restores, and would require the client to be clever. I'm all for allowing this kind of optimisation while writing normally to the database, and for not requiring the client to think too hard. Matthew -- All of this sounds mildly turgid and messy and confusing... but what the heck. That's what

Re: [PERFORM] Benchmark Data requested

the data bit. Matthew -- Failure is not an option. It comes bundled with your Microsoft product. -- Ferenc Mantfeld ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings

Re: [PERFORM] JDBC/Stored procedure performance issue

Hi Tom, Is there any way to work out what plan the query is using in side the function? I think I have a similar problem with a query taking much longer from inside a function than it does as a select statement. Regards Matthew Tom Lane wrote: Claire McLister [EMAIL PROTECTED] writes

Re: [PERFORM] RAID arrays and performance

list. Matthew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] Performance problems inside a stored procedure.

this to access the index and so was returning too many rows and then filtering them. It looks like I still have to take a hit of 2ms or so to call the function but I guess that is not unreasonable. Thanks for your help and to everyone who answered this thread. Regards Matthew. Euler Taveira de

[PERFORM] Performance issues migrating from 743 to 826

ms to run on 862 and 2.332 to run on 743. Thanks in advance for any help. Regards Matthew 8.2.6 shared_buffers = 500MB work_mem = 10MB maintenance_work_mem = 100MB effective_cache_size = 2048MB default_statistics_target = 1000 7.4.3 shared_buffers = 51200 sort_mem = 10240 vacuum_mem = 81920

Re: [PERFORM] Performance problems inside a stored procedure.

Ahh, sorry, I have been too aggressive with my cutting, I am running 8.2.6 and the function is below. Thanks. Matthew CREATE OR REPLACE FUNCTION sp_get_price_panel_id(int4, varchar, varchar, varchar, bpchar) RETURNS SETOF t_market_price_panel AS $BODY$ SELECT * FROM market mrkt JOIN

[PERFORM] Performance problems inside a stored procedure.

maintenance_work_mem = 100MB effective_cache_size = 2048MB default_statistics_target = 1000 Thanks for any help. Regards Matthew. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org

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

when the queue really is full. The hope would be that that would never happen. Matthew ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [PERFORM] Performance issues migrating from 743 to 826

using Thunderbird, maybe I need to upgrade. On Jan 28, 2008 9:27 AM, Matthew Lunnon [EMAIL PROTECTED] wrote: Scott Marlowe wrote: On Jan 28, 2008 5:41 AM, Matthew Lunnon [EMAIL PROTECTED] wrote: default_statistics_target = 1000 That's very high for the default. Planning times

Re: [PERFORM] Performance issues migrating from 743 to 826

Hi Scott, Thanks for your time Regards Matthew Scott Marlowe wrote: On Jan 28, 2008 5:41 AM, Matthew Lunnon [EMAIL PROTECTED] wrote: Hi I am investigating migrating from postgres 743 to postgres 826 but although the performance in postgres 826 seems to be generally better there are some

<    1   2   3   4   5   6   >