Re: [PERFORM] Postgres not using all RAM (Huge Page activated on a 96GB RAM system)

stgres 20 0 24.722g 14812 12956 S 0.3 0.0 0:07.36 > postgres > > > 9068 postgres 20 0 24.722g 6380 4232 S 0.3 0.0 0:02.15 > postgres > > > 9065 postgres 20 0 24.727g 10368 3516 S 0.0 0.0 0:04.24 > postgres > > > 9066 postgres 20 0 24.722g 4100 2248 S 0.0 0.0 0:06.04 > postgres > > > 9067 postgres 20 0 24.722g 4100 2248 S 0.0 0.0 0:01.37 > postgres > > > 9069 postgres 20 0 161740 4596 2312 S 0.0 0.0 0:04.48 > postgres > > What’s wrong with this? There isn’t something wrong in RAM usage? > > Thank you all >Pietro > -- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.'

Re: [PERFORM] jsonb_agg performance

xt. Rendering jsonb as text to the client involves a lot more processing. cheers andrew -- 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] problem with select *

. You should be using a cursor. cheers andrew -- 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] pg bouncer issue what does sv_used column means

Please do not cross-post on the PostgreSQL lists. Pick the most appropriate list to post to and just post there. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [PERFORM] Fastest Backup Restore for perf testing

application/OS/anything is no issue for me—there’s no data for me to lose. Thanks! Read all of this chapter. http://www.postgresql.org/docs/current/static/backup.html cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your

Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows

/FreeBSD do not suffer from this issue in nearly the same manner. jD You might consider a CLUSTER or VACUUM FULL to re-write the table with less fragmentation. Or pg_repack if you can't handle the lockup time that these involve. cheers andrew -- Sent via pgsql-performance mailing list

Re: [PERFORM] Number of Columns and Update

the whole row, not just the updated columns. I think you are overthinking it. cheers andrew -- 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] Re: [SQL] querying with index on jsonb slower than standard column. Why?

. I would be inclined to add the operator and see how cumbersome people find it. I suspect in many cases it might be sufficient. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [PERFORM] Re: [SQL] querying with index on jsonb slower than standard column. Why?

seems to me to be going in the wrong direction. cheers andrew -- 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] Postgres does not use indexes with OR-conditions

redundant. Could you not rewrite it as something this?: where fd.creation_time = '2011-11-07 10:39:07.285022+08' and (fd.creation_time '2011-11-07 10:39:07.285022+08' or fd.financial_document_id 100) cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance

[PERFORM] assignment vs SELECT INTO

I found out today that direct assignment to a composite type is (at least in my test) about 70% faster than setting it via SELECT INTO. That seems like an enormous difference in speed, which I haven't really been able to account for. Test case: andrew=# \d abc Table public.abc

Re: [PERFORM] assignment vs SELECT INTO

On 11/03/2014 03:24 PM, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: andrew=# do $x$ declare r abc; begin for i in 1 .. 1000 loop select 'a','b',i into r.x,r.y,r.z; end loop; end; $x$; DO Time: 63731.434 ms andrew=# do $x$ declare r abc; begin for i

Re: [PERFORM] Query with large number of joins

and not views, setting it to something like 25 should do the trick. You also haven't told us what settings you have for things like effective_cache_size, which can dramatically affect query plans. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org

Re: [PERFORM] char(N), varchar(N), varchar, text

no big performance differences? Thanks alot! Emi Why do you need to ask if you already have the answer? Depesz is right. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [PERFORM] help: function failing

forum for this query. usage questions should be on pgsql-general. cheers andrew -- 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] postgres 9.3 vs. 9.4

not tell me where the bottleneck is. Is this is defensively not the disk IO. This is when you dig out tools like perf, maybe. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [PERFORM] Tuning Postgres for Single connection use

performance to degrade on Windows, while that threshold is much higher on *nix. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

[PERFORM] query against large table not using sensible index to find very small amount of data

I have a fairly large table (~100M rows), let's call it events, and among other things it has a couple of columns on it, columns that we'll call entity_type_id (an integer) and and published_at (a timestamp). It has, among others, indices on (published_at) and (entity_type_id, published_at). A

Re: [PERFORM] query against large table not using sensible index to find very small amount of data

Your understanding of the utility of multi-part indices does not jive with my own. While I agree that a partial index might be in order here, that ought just be a performance optimization that lowers the footprint of the index from an index size and index maintenance standpoint, not something

Re: [PERFORM] Are there some additional postgres tuning to improve performance in multi tenant system

usually use the term multi-tenancy to refer to different postgres instances running on the same machine, rather than different databases within a single instance of postgres. So lease describe your setup in more detail. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance

Re: [PERFORM] Are there some additional postgres tuning to improve performance in multi tenant system

On 12/28/2013 08:46 AM, ankush upadhyay wrote: On Sat, Dec 28, 2013 at 6:50 PM, Andrew Dunstan and...@dunslane.net mailto:and...@dunslane.net wrote: On 12/28/2013 12:19 AM, ankush upadhyay wrote: Hello All, I am using multi tenant system and doing performance testing

Re: [PERFORM] Current query of the PL/pgsql procedure.

this for example: http://www.depesz.com/2010/03/18/profiling-stored-proceduresfunctions/ Also, the auto-explain module can peer inside functions. See http://www.postgresql.org/docs/current/static/auto-explain.html cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance

Re: [PERFORM] Postgresql in a Virtual Machine

application and your workload. And yes, I've used it. Full disclosure: I have done work paid for by Heroku. cheers andrew -- 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] Postgresql in a Virtual Machine

about the worst case in my experience. Try pre-allocated VirtIO disks on an LVM volume group - you should get much better performance. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [PERFORM] Postgresql in a Virtual Machine

be suitable for many workloads. Maybe the advice is a bit out of date. cheers andrew -- 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 sort

and think it's doing a good job. In your case it should be relatively straightforward. cheers andrew -- 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] Performance bug in prepared statement binding in 9.2?

transaction_timeout, or maybe transaction_idle_timeout. cheers andrew -- 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] Performance bug in prepared statement binding in 9.2?

this one. cheers andrew -- 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] Performance bug in prepared statement binding in 9.2?

these days and thus might help to reduce the impact of the longrunning transactions. Otherwise you will have to shorten those... Yeah, we're looking at eliminating them. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your

Re: [PERFORM] Intermittent hangs with 9.2

on a 48Gb box. What happens if you dial that back to, say, 12Gb? cheers andrew -- 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] Performance bug in prepared statement binding in 9.2?

[.] pg_verify_mbstr_len cheers andrew -- 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] Varchar vs foreign key vs enumerator - table and index size

, because those things would require processing tables where the type is used, unlike the simple things. But neither of these is required for typical use cases. For most uses of this kind they are very efficient both in storage and processing. cheers andrew -- Sent via pgsql-performance

Re: [PERFORM] Hstore VS. JSON

in this respect. You should test the storage effects with your data. On 9.2 for your data hstore might be a better bet, since in 9.2 hstore has more operators available natively. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes

Re: [PERFORM] Process in state BIND, authentication, PARSE

given us nearly enough information about your setup. We'd need to see your configuration settings and have some details of the machine and where connections are coming from to diagnose it further. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make

Re: [PERFORM] Dynamic queries in stored procedure

don't want to use orm. It's a matter of taste. Pretty much every PL has facilities for constructing and running dynamic sql. PLPgsql ,PLPerl, PLV8 ... cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http

Re: [PERFORM] Partitions not Working as Expected

EDB haven't marked their function immutable - it's not. cheers andrew -- 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] PostgreSQL settings for running on an SSD drive

you assume that cache misses will be higher for random reads than for sequential reads. cheers andrew -- 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] Thinking About Correlated Columns (again)

for any given table would be required. cheers andrew -- 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] template1 vacuuming consuming much time compared to another production DBs

On 04/22/2013 07:31 AM, pradeep singh wrote: Hi, I am using postgresql 8.1 DB. Why are you using a release of Postgres that is way out of date and unsupported? cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your

Re: [PERFORM] Speed of EXCECUTE in PL/PGSQL

and planned each time. You should expect it to be quite a bit slower, and avoid using EXECUTE wherever possible. cheers andrew -- 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] High CPU usage after partitioning

it. Constraint exclusion does not work in cases like this. It only works with static expressions (such as a literal date in this case). cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [PERFORM] High CPU usage after partitioning

'execute'? cheers andrew -- 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] backend suddenly becomes slow, then remains slow

On 12/26/2012 11:03 PM, Jeff Janes wrote: On Fri, Dec 14, 2012 at 10:40 AM, Andrew Dunstan andrew.duns...@pgexperts.com wrote: One of my clients has an odd problem. Every so often a backend will suddenly become very slow. The odd thing is that once this has happened it remains slowed down

[PERFORM] backend suddenly becomes slow, then remains slow

anything like this? cheers andrew -- 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] backend suddenly becomes slow, then remains slow

On 12/14/2012 02:56 PM, Tom Lane wrote: Andrew Dunstan andrew.duns...@pgexperts.com writes: One of my clients has an odd problem. Every so often a backend will suddenly become very slow. The odd thing is that once this has happened it remains slowed down, for all subsequent queries. Zone

Re: [PERFORM] Why does the number of rows are different in actual and estimated.

to be out by several orders of magnitude. Guaranteeing estimates within bounded accuracy and in a given short amount of time (you don't want your planning time to overwhelm your execution time) isn't possible. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance

[PERFORM] track_activity_query_size

Is there a performance downside to setting track_activity_query_size to a significantly larger value than the default 1024 (say 10240), given that there's plenty of memory to spare? cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes

Re: [PERFORM] Read rows deleted

or a multiplatform code that let read the delete rows of a table without writing of a table file? This isn't a performance related question. Please ask on the correct list (probably pgsql-general). cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org

[PERFORM] encouraging index-only scans

to encourage such scans that's a but less violent than this? cheers andrew -- 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] encouraging index-only scans

On 12/12/2012 04:32 PM, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: A client is testing a migration from 9.1 to 9.2, and has found that a large number of queries run much faster if they use index-only scans. However, the only way he has found to get such a plan is by increasing

Re: [PERFORM] encouraging index-only scans

On 12/12/2012 05:12 PM, Andrew Dunstan wrote: On 12/12/2012 04:32 PM, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: A client is testing a migration from 9.1 to 9.2, and has found that a large number of queries run much faster if they use index-only scans. However, the only way

Re: xfs perform a lot better than ext4 [WAS: Re: [PERFORM] Two identical systems, radically different performance]

On 12/05/2012 11:51 AM, Jean-David Beyer wrote: I thought that postgreSQL did its own journalling, if that is the proper term, so why not use an ext2 file system to lower overhead? Postgres journalling will not save you from a corrupt file system. cheers andrew -- Sent via pgsql

Re: [PERFORM] Postgres configuration for 8 CPUs, 6 GB RAM

. You would normally expect maintenance_work_mem to be higher - sometimes much higher. Apart from that, it's going to be impossible to tell what your problem is without seeing actual slow running queries and their corresponding explain analyse output. cheers andrew -- Sent via pgsql

Re: [PERFORM] Poor performance using CTE

then release notes, since a lot of people I know will need to do some extensive remediation before moving to such a release. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [PERFORM] Poor performance using CTE

On 11/21/2012 09:59 AM, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: If we're going to do it can we please come up with something more intuitive and much, much more documented than OFFSET 0? And if/when we do this we'll need to have big red warnings all over then release notes

Re: [PERFORM] Poor performance using CTE

as (blah) select blah; Not global at all. Then you have to unset it again, which is ugly. You might even want it applying to *part* of a query, not the whole thing, so this strikes me as a dead end. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org

Re: [PERFORM] Poor performance using CTE

. WITH NO FENCE foo AS (SELECT ...) 3. WITH NOT FENCE foo AS (SELECT ...) I loke the firsat variant, but the 3rd is most SQL standardish! As Tom (I think) pointed out, we should not have a syntax tied to CTEs. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance

[PERFORM] partitioning versus clustering

Postgres Performance Wizards, I am a few years into developing and operating a system underpinned by Postgres that sees the arrival a significant number of events around the clock, not an epic amount of data, but enough to be challenging to me, in particular when system downtime is not very

Re: [PERFORM] Poor performance using CTE

from it) to itself? In any case, you could almost certainly recast it and have it run fast by first filtering on the tracking number. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [PERFORM] Poor performance using CTE

and mechanically cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

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

because this behaviour lets me get better plans. Without that I'll be back to using the offset 0 hack. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [HACKERS] [PERFORM] pg_dump and thousands of schemas

is not just a noise word here. The fact that we have options to do other things doesn't mean that its primary design goal has changed. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [PERFORM] Remote access to Postgresql slow

Is your network link between server and client across the public internet? You need to check bandwidth and latency characteristics of your network. A simple test run following on server host and run it again on the client host. time psql [connect details] -c 'select now()' I access postgresql

Re: [PERFORM] add column with default value is very slow

, indexes included. See the description of ACCESS EXCLUSIVE lock at http://www.postgresql.org/docs/current/static/explicit-locking.html cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [PERFORM] best practice to avoid table bloat?

during the day but less active during night I think that the only only thing where Postgres is weak, is in this area (table and index bloat). For some reason for the same amount of data every day postgres consume a little more. Check out pg_reorg. cheers andrew -- Sent via pgsql

Re: [PERFORM] Odd blocking (or massively latent) issue - even with EXPLAIN

of behaviour on systems with massive catalogs (millions of tables and indexes). Could that be your problem? cheers andrew -- 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] queries are fast after dump-restore but slow again after some days dispite vacuum

a difference. If it does you might want to look into using pg_reorg periodically. cheers andrew -- 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] queries are fast after dump-restore but slow again after some days dispite vacuum

On 07/19/2012 11:13 AM, Felix Scheicher wrote: Andrew Dunstan andrew at dunslane.net writes: Try running CLUSTER on the relevant tables and see if it makes a difference. If it does you might want to look into using pg_reorg periodically. That worked like a charm! Many thanks. But how comes

Re: [PERFORM] DELETE vs TRUNCATE explanation

to this method of test db setup. cheers andrew -- 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

there are, even if it only wants one page right now. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

[PERFORM] Sequencial scan in a JOIN

(activequeueid , vstatus , ventrydate ); a_activity table has 1,216,134 rows Thanks in advance, Andrew

Re: [PERFORM] Sequencial scan in a JOIN

the default_statistics_target is set to 200, and I have run the analyze and reindex on these tables before writing the email. Andrew Date: Tue, 5 Jun 2012 08:15:45 -0500 From: stho...@optionshouse.com To: andrewjai...@hotmail.com CC: pgsql-performance@postgresql.org Subject: Re

Re: [PERFORM] query optimization

.) cheers andrew -- 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] scale up (postgresql vs mssql)

, temp_buffers and work_mem. cheers andrew -- 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] Performance of SQL Function versus View

and times of queries nested in functions which can't easily be got otherwise. cheers andrew -- 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] Update join performance issues

whatever is in the from clause to the table being updated. You almost never need it repeated in the from clause. cheers andrew -- 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] TCP Overhead on Local Loopback

On 04/01/2012 09:11 PM, Andrew Dunstan wrote: On 04/01/2012 08:29 PM, Claudio Freire wrote: On Sun, Apr 1, 2012 at 8:54 PM, Andrew Dunstanand...@dunslane.net wrote: You could try using Unix domain socket and see if the performance improves. A relevant link: He said Windows

Re: [PERFORM] TCP Overhead on Local Loopback

On 04/01/2012 06:01 PM, Andy wrote: You could try using Unix domain socket and see if the performance improves. A relevant link: He said Windows. There are no Unix domain sockets on Windows. (And please don't top-post) cheers andrew -- Sent via pgsql-performance mailing list (pgsql

Re: [PERFORM] TCP Overhead on Local Loopback

On 04/01/2012 08:29 PM, Claudio Freire wrote: On Sun, Apr 1, 2012 at 8:54 PM, Andrew Dunstanand...@dunslane.net wrote: You could try using Unix domain socket and see if the performance improves. A relevant link: He said Windows. There are no Unix domain sockets on Windows. (And please

Re: [PERFORM] Tablespaces on a raid configuration

the value if you were to have the tablespaces on different raid arrays. But what about on the same one? Not answering your question, but standard advice is not to use RAID 5 or 6, but RAID 10 for databases. Not sure if that still hold if you're using SSDs. cheers andrew -- Sent via pgsql

Re: [PERFORM] database slowdown while a lot of inserts occur

, if you're not using that already. It's not as efficient as COPY, but it's often a much less extensive change to the code. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [PERFORM] slow self-join query

, but that will change in the future. If all the rows have that value, then using the index would be silly. Postgres knows from the stats that ANALYZE calculates whether or not using an index is likely to be more efficient, and avoids doing so in cases where it isn't. cheers andrew -- Sent

Re: [PERFORM] PG as in-memory db? How to warm up and re-populate buffers? How to read in all tuples into memory?

in tens if not hundreds of Mb for any significantly sized database. cheers andrew -- 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] PG as in-memory db? How to warm up and re-populate buffers? How to read in all tuples into memory?

theoretical maximum will not be reached. Can the OP say that? I have no reason to think so. Hence I don't suggest 100M is OK on a 4G system. Well, obviously you need to know your workload. Nobody said otherwise. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance

Re: [PERFORM] Very long deletion time on a 200 GB database

partitioned by time and do the delete by just dropping partitions. There are numerous way he could get this to work. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [PERFORM] Very long deletion time on a 200 GB database

days, 60 days, 30 days. cheers andrew -- 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 slow as Function

be hard to say much without a self-contained example to try. He's using EXECUTE ... USING. Does that plan with the used parameter? cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http

Re: [PERFORM] Exploring memory usage

patterns. cheers andrew -- 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] Performance costs of various PL languages

look at pl/java. PLV8, which is not yet ready for prime time, maps many common Postgres types into native JS types without the use of Input/Output functions, which means the conversion is very fast. It's work which could very well do with repeating for the other PL's. cheers andrew -- Sent

[PERFORM] Query planner suggestion, for indexes with similar but not exact ordering.

at allowing some sort of in memory sort to be overlaid on an index if the statistics indicate that the sorts are very nearly ordered. Andrew

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

On 02/04/2011 02:32 AM, da...@lang.hm wrote: when a copy command is issued, I assume that there is some indication of how much data is going to follow. No of course there isn't. How would we do that with a stream like STDIN? Read the code. cheers andrew -- Sent via pgsql

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

misunderestimate more in the future when talking about planner errors. Might even try to slip it into the docs at some point in the future and see if anybody catches it. My wings take dream ... cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make

Re: [PERFORM] Best replication solution?

to see whether those features could be incorporated without the same complication. A -- Andrew Sullivan a...@crankycanuck.ca -- 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] Best replication solution?

know the system pretty well). A -- Andrew Sullivan a...@crankycanuck.ca -- 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] inheritance, and plans

Tom == Tom Lane t...@sss.pgh.pa.us writes: Andrew Gierth and...@tao11.riddles.org.uk writes: Type-dependent selection of operators has already been done as part of parse analysis, no? And the domain - base conversion is purely a relabelling, no? So what semantic change is possible

Re: [PERFORM] inheritance, and plans

, no? And the domain - base conversion is purely a relabelling, no? So what semantic change is possible as a result? -- Andrew (irc:RhodiumToad) -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [PERFORM] Deleting millions of rows

* FROM remnant; COMMIT; ANALYSE bigtable; works well because there is no possibility of my forgetting FKs. -- Sincerely, Andrew Lazarusmailto:and...@pillette.comBEGIN:VCARD VERSION:2.1 N:Lazarus;Andrew;;;Ph.D. FN:Andrew Lazarus, Ph.D. EMAIL;PREF;INTERNET:and...@pillette.com

Re: [PERFORM] Occasional Slow Commit

. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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 updates, poor IO

? A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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] Choosing a filesystem

. Can you please advise how to create logical partitions? I would listen to yourself before you listen to the expert. You sound right to me :) A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ -- Sent via pgsql-performance mailing list (pgsql-performance

  1   2   3   4   5   >