Re: [PERFORM] High rate of transaction failure with the Serializable Isolation Level

where they do in Pg, then the other products either have less strict (and arguably therefor less correct) serialisable isolation enforcement or they rely on blocking predicate locks. In the latter case it should be easy to tell because statements will block on locks where no ordinary row or table

Re: [PERFORM] Debugging writing load

ittle about this topic a while ago: http://blog.2ndquadrant.com/tracing-postgresql-perf/ but it's really a bit introductory. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-performance maili

Re: [PERFORM] High rate of transaction failure with the Serializable Isolation Level

ccur as there is no serialization >> execution order of the transactions that could produce the same result. > > As far as the inserts, your point is well-taken. But in this case, I have > eliminated the transactions that query or otherwise manipulate the > SETTELEMENT table.

Re: [PERFORM] High rate of transaction failure with the Serializable Isolation Level

nly really affect object level locks (tables, etc) according to the docs. I'd need to dig further to determine how to reduce or eliminate lock combining of row-level to page-level and page-level to object-level locks. -- Craig Ringer http://www.2ndQuadrant.com/ Postgre

Re: [PERFORM] High rate of transaction failure with the Serializable Isolation Level

but it detects many that other systems may not. To see what's going on and why MS SQL Server (version?) doesn't complain, it'd be best to boil each case down to a minimal reproducible test case that can be analyzed in isolation. PostgreSQL's isolationtester t

Re: [PERFORM] Volatility - docs vs behaviour?

On 06/30/2014 11:49 PM, Tom Lane wrote: > Craig Ringer writes: >> The docs say: > >> "For best optimization results, you should label your functions with the >> strictest volatility category that is valid for them." > > Yeah ... > >> ... but

[PERFORM] Volatility - docs vs behaviour?

Pavel was saying. I know STRICT can prevent inlining (unfortunately, though necessarily), but it seems inexplicable that IMMUTABLE should. If it can, then the documentation is wrong. Which is it? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Sup

Re: [PERFORM] Slow query-plan generation (fast query) PG 9.2

S select table.id from db.table left join db.tablepro on db.id = tablepro.table_id where table.fts @@ to_tsquery('english','q12345') ; and then: EXPLAIN ANALYZE EXECUTE testq; -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Suppor

Re: [PERFORM] How clustering for scale out works in PostgreSQL

icas is still a cluster. If you mean "transparent multi-master clustering", well that's another thing entirely. I strongly recommend you go back to basics. Evaluate the capacity of the server you've got, update PostgreSQL, characterize the load, do some basic tuning, benchmark

Re: [PERFORM] How clustering for scale out works in PostgreSQL

On 08/30/2013 01:48 AM, bsreejithin wrote: > Ya..sure...Migration to 9.2 is one of the activities planned and in fact > it's already on track.Thanks Thomas You'll want to re-do your performance testing; a huge amount has changed since 8.2. -- Craig Ringer

Re: [PERFORM] Interesting case of IMMUTABLE significantly hurting performance

immutable; and there's no sign it's parsed each time. So it's not just the IMMUTABLE flag. If nothing else this strongly suggests that the docs don't cover this area particularly comprehensively. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL

Re: [PERFORM] Interesting case of IMMUTABLE significantly hurting performance

am surprised to hear it's the case for IMMUTABLE as well. That seems ... counter-intuitive. Not to mention undocumented as far as I can see. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-pe

Re: [PERFORM] Interesting case of IMMUTABLE significantly hurting performance

On 08/14/2013 08:41 AM, Craig Ringer wrote: > Hi folks > > I've run into an interesting Stack Overflow post where the user shows > that marking a particular function as IMMUTABLE significantly hurts the > performance of a query. Here's `perf` report data for the two.

[PERFORM] Interesting case of IMMUTABLE significantly hurting performance

le now, but I wanted to raise this on the list for comment/opinions, since it's very counter-intuitive. IIRC docs don't suggest that IMMUTABLE can ever be more expensive. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &

Re: [PERFORM] Do I have a hardware or a software problem?

ss that way, but you don't need a second machine as a streaming replication follower. barman might is worth checking out as a management tool for PITR backups. If the data is fairly low-value you could even just take nightly backups and accept the risk of losing some data. -- Craig Ringer

Re: [PERFORM] Do I have a hardware or a software problem?

amily http://www.ocztechnology.com/res/manuals/OCZ_SSD_Breakdown_Q2-11_1.pdf The only way I'd use those for a production server was if I had synchronous replication running to another machine with trustworthy, durable storage - and if I didn't mind some downtime to restore the corrupt

Re: [PERFORM] Do I have a hardware or a software problem?

an issue with your SSDs is to do plug-pull testing and find out. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

Re: [PERFORM] Do I have a hardware or a software problem?

better spent on faster, higher quality SSDs with their own fast write caches. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

Re: [PERFORM] Do I have a hardware or a software problem?

ardware RAID controllers. I suspect a mid- to high end HW RAID unit will generally win. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

Re: [PERFORM] Do I have a hardware or a software problem?

Use a RAID10 of four or six SSDs. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- 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] Hints (was Poor performance using CTE)

eir code considerably, though, going by past experience with standard_conforming_strings, etc, but it'd work. -- Craig Ringer -- 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] PQconnectStart/PQconnectPoll

n external connection pool. Have your app connect to PgBouncer, and PgBouncer connect to PostgreSQL. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

Re: [PERFORM] Poor performance using CTE

queries were executed as written, so Pg is free to transform them so long as it doesn't change the results. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-performance mailing list (pgsql-performanc

Re: [PERFORM] Poor performance using CTE

e to invent a new syntax for this, can we please come up with >> something that's more widely applicable than just the WITH syntax. >> Something that you could use to replace OFFSET 0 in a subquery, too. >> >> - Heikki > WITH FENCE foo AS (SELECT ...) > default? That doesn't bind tightly enough to a specific CTE term. Consider: WITH FENCE foo AS (SELECT ...), bar AS (SELECT ...) SELECT * FROM bar; Are we fencing just foo? Or all expressions? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

Re: [PERFORM] Hints (was Poor performance using CTE)

ise where it needs a little help. I think it's time to admit that and get the syntax in place for CTEs so there's room to optimize them later, rather than cementing CTEs-as-fences in forever as a Pg quirk. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Dev

Re: [PERFORM] Poor performance using CTE

used to using CTEs as query hints, it'd probably cause performance regressions in working queries. Perhaps more importantly, Pg would have to prove that doing so didn't change queries that invoked functions with side-effects to avoid changing the results of currently vali

Re: SOLVED - RE: [PERFORM] Poor performance using CTE

often can't use CTEs to clean up hard-to-read queries because of the optimisation barrier, so I have to create a temporary view, temporary table, or use nested subqueries in FROM instead. Ugly. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7

Re: SOLVED - RE: [PERFORM] Poor performance using CTE

se VOLATILE functions or functions with side-effects couldn't be optimised into other queries. Simple CTEs could be, though, and there are times I've really wished I could use a CTE but I've had to use a set-returning subquery to get reasonable plans. -- Craig Ringer

Re: [PERFORM] PostreSQL v9.2 uses a lot of memory in Windows XP

stgresql service is very quick in > restarting. I hope it'll understand. And, of course, because PostgreSQL looks like it uses a TON of memory, even when it's really using only a small amount. This has been an ongoing source of confusion, but it's one that isn't going to go

Re: [PERFORM] PostreSQL v9.2 uses a lot of memory in Windows XP

process that probably is the main cause of the > lagging. It's going to be everything adding up. Chrome, Eclipse, Firefox, all fighting for RAM. BTW, chrome uses a multi-process architecture like PostgreSQL, but unlike PostgreSQL it does not use shared memory, so you can tell

Re: [PERFORM] PostreSQL v9.2 uses a lot of memory in Windows XP

ure. They're processes not threads. Each process only uses a fairly small amount of memory - the exact amount depends on settings like work_mem and what the queries running are doing, but it's usually not much. Most of the apparent use is shared memory. -- Craig Ringer http:

Re: [PERFORM] Thousands databases or schemas

do you put a number to it when something is a slow and gradual drop in performance? And when one person's "performs adequately" is another's "way too slow" ? -- Craig Ringer -- 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] Slow Delete : Seq scan instead of index scan

(I think; I might be misremembering the versions). Please specify your PostgreSQL version in all questions. See https://wiki.postgresql.org/wiki/Slow_Query_Questions -- Craig Ringer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subs

Re: [PERFORM] Slow Delete : Seq scan instead of index scan

name" from psql? -- Craig Ringer -- 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] SELECT AND AGG huge tables

On 10/16/2012 04:59 AM, houmanb wrote: There is an Index on T.c. But would it help to partition the table by T.c? You should really post EXPLAIN ANALYZE for questions like this. See https://wiki.postgresql.org/wiki/Slow_Query_Questions -- Craig Ringer -- Sent via pgsql-performance

Re: [PERFORM] Drawbacks of create index where is not null ?

themselves. The planner isn't super-smart about how it matches index WHERE conditions to query WHERE conditions, so you'll want to use exactly the same condition text where possible. -- Craig Ringer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.or

Re: [PERFORM] hash aggregation

ie create the index in descending order. -- Craig Ringer -- 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] Scaling 10 million records in PostgreSQL table

tion or log shipping to a local hot standby on real physical hardware, then do the query there. -- Craig Ringer -- 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] Strange behavior after upgrade from 9.0 to 9.2

tions -- Craig Ringer -- 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] A Tale of 2 algorithms

f its indexes? Something else? -- Craig Ringer -- 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] Are there known performance issues with defining all Foreign Keys as deferrable initially immediate

On 09/16/2012 11:37 PM, Tom Lane wrote: Craig Ringer writes: Found it, it's in the NOTES for CREATE TABLE. http://www.postgresql.org/docs/current/static/sql-createtable.html: When a UNIQUE or PRIMARY KEY constraint is not deferrable, PostgreSQL checks for uniqueness immediately whene

Re: [PERFORM] Are there known performance issues with defining all Foreign Keys as deferrable initially immediate

On 09/16/2012 09:45 PM, Craig Ringer wrote: This seems under-documented and I haven't found much good info on it, so the best thing to do is test it. Found it, it's in the NOTES for CREATE TABLE. http://www.postgresql.org/docs/current/static/sql-createtable.html: When a UNIQUE

Re: [PERFORM] Are there known performance issues with defining all Foreign Keys as deferrable initially immediate

perform better or at least not hit limits that DEFERRABLE INITIALLY DEFERRED might hit in Pg. This seems under-documented and I haven't found much good info on it, so the best thing to do is test it. -- Craig Ringer -- Sent via pgsql-performance mailing list (pgsql-performance@pos

Re: [PERFORM] query performance, where goes time?

ast that timing accuracy will be an issue on some systems, and so will scheduler jitter etc. -- Craig Ringer -- 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] JDBC 5 million function insert returning Single Transaction Lock Access Exclusive Problem

rectly, an improvement to exception handling efficiency. Does your function use BEGIN ... EXCEPTION to (say) handle data validation errors? -- Craig Ringer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mail

Re: [PERFORM] Vacuum problems with 9.1

ause this exact message, but check: select * from pg_prepared_xacts ; to see if you have any prepared transactions (from two-phase commit) lying around. If you don't use XA or 2PC, consider setting max_prepared_transactions to 0 in postgresql.conf if it isn't already. -- C

Re: [PERFORM] Postgres Upgrade from 8.4 to 9.1

. Upgrades from 8.4 to 9.0 or 9.1 require a dump and reload or the use of the pg_upgrade tool. You can't just install the new version and start it on your old database. 3.Any known issues and changes required to be done in the application for this upgrade. See the release notes. -- Craig Ringer

Re: [PERFORM] Postgresql - performance of using array in big database

t using pg_bulkload. If you can't or don't want to do that, then at least use COPY to load big batches of your data. -- Craig Ringer

Re: [PERFORM] Is drop/restore trigger transactional?

in a new tx to avoid locking the table for ages though. -- Craig Ringer -- 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] Odd blocking (or massively latent) issue - even with EXPLAIN

appears to click back into place at the same time). How many concurrent connections do you have? -- Craig Ringer -- 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] query overhead

caching the record keys for the set and only visiting the database for the specific records on each "get next" - hence the questions about round trip overhead for small queries. Given that pattern, why aren't you using a cursor? Do you need to see concurrent changes? Is t

Re: [PERFORM] A very long running query....

ALTER TABLE ... ALTER COLUMN ... SET STATISTICS to raise the targets on columns where you're seeing bad statistics estimates. http://www.postgresql.org/docs/9.1/static/sql-altertable.html Also make sure autovaccum is running frequently so it keeps the stats up to date. -- Craig Ringer

Re: [PERFORM] very very slow inserts into very large table

oom here, but only a limited amount, and at the cost of reduced scan efficiency. -- Craig Ringer -- 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] query overhead

erable, yeah, but you get very fast shared-access reads as a trade-off and it's much closer to your app's old DB design. It depends a lot on your workload. -- Craig Ringer

[PERFORM] Proposed change for 9.3(?): Require full restart to change fsync parameter, not just pg_ctl reload

http://archives.postgresql.org/message-id/4ffccac4.4030...@ringerc.id.au On 07/16/2012 09:37 AM, Tom Lane wrote: Craig Ringer writes: On 07/16/2012 02:29 AM, Tom Lane wrote: Yeah, you have a point there. It's not real clear that switching fsync from off to on is an operation that we can make a

Re: [PERFORM] Any tool/script available which can be used to measure scalability of an application's database.

thing out of shared_buffers, so it can also avoid competition for cache. (If anyone ever wants concurrent scans badly enough to implement them, full table scans with effective_io_concurrency > 1 will become a *lot* faster for some types of query). -- Craig Ringer -- Sent via pgsql-perfo

Re: [PERFORM] Any tool/script available which can be used to measure scalability of an application's database.

vestigate, it just means your trials don't prove anything and the optimisations you make based on what you learn may not gain you much. -- Craig Ringer

Re: [PERFORM] Any tool/script available which can be used to measure scalability of an application's database.

ts" problem and massive inefficient multiple left outer joins are classics. Thus, you can't really evaluate the scalability of the database under load separately from the application that's using it and the workload. -- Craig Ringer

Re: [PERFORM] PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.

ed in the mechanics of what MySQL's truncates are doing. -- Craig Ringer

Re: [PERFORM] query overhead

me_other_var = [expression] WHERE [expression] then you'll get much better results from Pg. -- Craig Ringer

Re: [PERFORM] how could select id=xx so slow?

hem when they're that big. Use pg_size_pretty(pg_relation_size('index_name')) to get the index sizes and compare to the pg_relation_size of the table. It might be informative. You may see some insert performance benefits with a non-100% fill factor on the indexes, but with possible performance costs to index scans. -- Craig Ringer

Re: [PERFORM] DELETE vs TRUNCATE explanation

On 07/12/2012 02:12 PM, Daniel Farina wrote: On Wed, Jul 11, 2012 at 6:41 PM, Craig Ringer wrote: On 07/12/2012 06:51 AM, Daniel Farina wrote: 15x slower. This is a Macbook Air with full disk encryption and SSD disk with fsync off, e.g. a very typical developer configuration. Don't use

Re: [PERFORM] how could select id=xx so slow?

d in that your queues may just keep on getting deeper or time out. In that case, you certainly need to optimise your queries, tune your database, and/or get bigger hardware. -- Craig Ringer

Re: [PERFORM] how could select id=xx so slow?

by slow queries. Yep - assumptions are a killer like that. Now you know to watch your system load with iostat, vmstat, top, etc and to monitor your overall load. -- Craig Ringer

Re: [PERFORM] DELETE vs TRUNCATE explanation

se in the past, but it's becoming mainstream and is worth being aware of. That said, the group of people who care about this most are not well represented as active contributors to PostgreSQL. I'd love it if you could help start to change that by stepping in and taking a little time t

Re: [PERFORM] DELETE vs TRUNCATE explanation

On 07/11/2012 01:22 PM, Daniel Farina wrote: On Tue, Jul 10, 2012 at 5:37 PM, Craig Ringer wrote: Hi After seeing a few discussions here and on Stack Overflow I've put together a quick explanation of why "DELETE FROM table;" may be faster than "TRUNCATE table" for peo

Re: [PERFORM] DELETE vs TRUNCATE explanation

DELETE FROM table; but also prevents bloat. It's a weird little corner case, but with database-backed unit testing it's going to become a more significant one whether or not it feels like it makes any sense. -- Craig Ringer -- Sent via pgsql-performance mailing list (pgsql-p

Re: [PERFORM] how could select id=xx so slow?

-forth discussion. -- Craig Ringer

[PERFORM] DELETE vs TRUNCATE explanation

w long it takes. I'd love it if a few folks who know the guts were to take a look and verify its correctness: http://stackoverflow.com/a/11423886/398670 -- Craig Ringer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription:

Re: [PERFORM] how could select id=xx so slow?

y if you have lots and lots (hundreds) of connections to the database all trying to do work at once without any kind of admission control or pooling/queuing. In that case, introducing a connection pool like PgBouncer may help. -- Craig Ringer

Re: [PERFORM] how could select id=xx so slow?

ow enough to trigger slow query logging" ? Do you have a "log_min_duration_statement" directive set in your postgresql.conf ? -- Craig Ringer -- 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] Paged Query

your autovaccum is running regularly it's usually a very good approximation, too. Sounds like this hack may become unnecessary in 9.2 though. -- Craig Ringer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription:

Re: [PERFORM] Paged Query

On 07/09/2012 09:22 PM, Shaun Thomas wrote: On 07/09/2012 07:02 AM, Craig Ringer wrote: Do do cursors. Did you mean "Do not use cursors" here? Oops. "So do cursors". Then the user goes away on a week's holiday and leaves their PC at your "next" button.

Re: [PERFORM] Paged Query

efined costs, albeit not very nice ones. -- Craig Ringer -- 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] Create tables performance

es for you too. Do you think there could be some configuration tuning to do to improve the performance for create tables ? Or do I have to use tablespaces because 10 files in a single folder is a too many for OS ? That won't be a problem unless your OS and file system are truly crap. -- Craig Ringer

Re: [PERFORM] PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.

over simply sending DELETE FROM test1; DELETE FROM test2; This all smells like premature optimisation of cases that don't matter. What problem are you solving with this? -- Craig Ringer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make chang

Re: [PERFORM] PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.

On 07/06/2012 07:38 PM, Daniel Farina wrote: On Fri, Jul 6, 2012 at 4:29 AM, Craig Ringer wrote: 1) Truncate each table. It is too slow, I think, especially for empty tables. Really?!? TRUNCATE should be extremely fast, especially on empty tables. You're aware that you can TRUNCATE

Re: [PERFORM] PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.

On 07/06/2012 07:29 PM, Craig Ringer wrote: On 07/03/2012 11:22 PM, Stanislaw Pankevich wrote: I cannot! use transactions. Everything in PostgreSQL uses transactions, they are not optional. I'm assuming you mean you can't use explicit transaction demarcation, ie BEGIN and COMMI

Re: [PERFORM] PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.

ast, get rid of iteration. Do it all in one query or a couple of simple queries. Minimize the number of round-trips and queries. I'll be truly stunned if the fastest way isn't to just TRUNCATE all the target tables in a single statement (not iteratively one by one with separate TRUNCATEs). -- Craig Ringer

Re: [PERFORM] how could select id=xx so slow?

lock during maintenance work (say, an ALTER TABLE). It's also quite possible that it was held up by a slow checkpoint; check your logs to see if there are warnings about checkpoint activity. -- Craig Ringer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To

Re: [PERFORM] select operations that generate disk writes

s/9.1/interactive/runtime-config-statistics.html Hint bits, too: http://wiki.postgresql.org/wiki/Hint_Bits -- Craig Ringer

Re: [PERFORM] Introducing the TPC-V benchmark, and its relationship to PostgreSQL

o the final configuration is important, especially when trying new things. -- Craig Ringer -- 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 need for clustered indexes to boost TPC-V performance

leases, because 8.4, 9.0, 9.1 and 9.2 are distinct releases with different feature sets, so "postgresql 9" doesn't mean much. -- Craig Ringer -- 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 need for clustered indexes to boost TPC-V performance

d to keeping track of conversations, to inline reply style, etc. -- Craig Ringer

Re: [PERFORM] The need for clustered indexes to boost TPC-V performance

On 07/06/2012 04:52 AM, Samuel Gendler wrote: On Thu, Jul 5, 2012 at 1:37 PM, Reza Taheri > wrote: I provided more config details in an earlier email. I hate to disagree, but unless I didn't get a message sent to the list It looks like that might be the ca

Re: [PERFORM] The need for clustered indexes to boost TPC-V performance

clustered indexes aren't on there or at least aren't easily found. It's certainly a much-desired feature despite its apparent absence from the TODO. http://wiki.postgresql.org/wiki/PostgreSQL_9.2_Development_Plan http://wiki.postgresql.org/wiki/PostgreSQL_9.2_Open_Items -- Craig Ringer

Re: [PERFORM] The need for clustered indexes to boost TPC-V performance

On 07/04/2012 03:57 PM, Thomas Kellerer wrote: Craig Ringer, 04.07.2012 07:43: I'm not sure what the best option for getting a 9.2 beta build for Windows is. Download the ZIP from here: http://www.enterprisedb.com/products-services-training/pgbindownload Gah, I'm blind. I look

Re: [PERFORM] The need for clustered indexes to boost TPC-V performance

red feature despite its apparent absence from the TODO. http://wiki.postgresql.org/wiki/PostgreSQL_9.2_Development_Plan http://wiki.postgresql.org/wiki/PostgreSQL_9.2_Open_Items -- Craig Ringer

Re: [PERFORM] Introducing the TPC-V benchmark, and its relationship to PostgreSQL

s development but could easily miss your message. If you haven't read Greg' book "PostgreSQL High Performance" it's probably a good idea to do so. -- Craig Ringer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your

Re: [PERFORM] index-only scan is missing the INCLUDE feature

On 06/20/2012 11:32 PM, Shaun Thomas wrote: On 06/20/2012 09:11 AM, Craig Ringer wrote: For those of us who don't know MS-SQL, can you give a quick explanation of what the INCLUDE keyword in an index definition is expected to do, or some documentation references? He's talking abo

Re: [PERFORM] index-only scan is missing the INCLUDE feature

rd in an index definition is expected to do, or some documentation references? It's possible to guess it somewhat from your description, but it's helpful to be specific when asking a question about features from another DBMS. -- Craig Ringer

Re: [PERFORM] pg 9.1 brings host machine down

aking params based on benchmarking and examination of runtime performance is your only real option for now. -- Craig Ringer -- 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] Dramatic change in memory usage with version 9.1

avior of those has changed significantly in 9.1 and they _are_ more expensive in RAM terms now. -- Craig Ringer -- 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] autovacuum, exclude table

Top-posting because this is context free: You need to provide more info for anybody to help you. Are the tables append-only or are deletes/updates also performed? Also this: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems On Dec 12, 2011 10:26 PM, "Anibal David Acosta" wrote: > I h

Re: [PERFORM] copy vs. C function

7;s innards to answer this one beyond that suggestion, sorry. -- Craig Ringer -- 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] Some question about lazy subquery/procedures execution in SELECT ... ORDER BY... LIMIT N queries

ttp://www.postgresql.org/docs/current/static/sql-createfunction.html . -- Craig Ringer -- 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] IMMUTABLE STABLE functions, daily updates

On Nov 10, 2011 9:26 PM, "Thom Brown" wrote: > > On 10 November 2011 13:05, Sorin Dudui wrote: > > Hi, > > > > > > > > I have some functions that select data from tables which are daily or > > monthly updated. My functions are marked as STABLE. I am wondering if they > > perform better if I mark

Re: [PERFORM] Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc?

On 11/03/2011 04:22 AM, Igor Neyman wrote: Hints here we come :) Pfft! No more than `VOLATILE' vs `STABLE' vs `IMMUTABLE'. It's a semantic difference, not just a performance hint. That said, I'm not actually against performance hints if done sensibly. -- C

Re: [PERFORM] procedure takes much more time than its query statement

it? If so, you're being bitten by a generic query plan. The server does a better job when it knows what parameter is used when it's planning the statement. To work around it, you can use the PL/PgSQL 'EXECUTE ... USING ...' statement to force a re-plan of the statement for

Re: [PERFORM] Heavy contgnous load

rency, crash safety, fast querying, and data integrity, and they provide those at the cost of slower data insertion among other things. -- Craig Ringer -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

  1   2   3   4   >