Re: [PERFORM] Problems with autovacuum

2009-06-09 Thread Alvaro Herrera
. Glitches fixed in this version; will apply shortly to 8.3 and HEAD. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support Index: src/backend/postmaster/autovacuum.c

Re: [PERFORM] Problems with autovacuum

2009-06-09 Thread Alvaro Herrera
Alvaro Herrera escribió: Tom Lane escribió: Well, that code isn't even correct I think; you're not supposed to modify a GUC variable directly. I think you should just silently use a naptime of at least X without changing the nominal GUC variable. And definitely without the WARNING

Re: [PERFORM] Problems with autovacuum

2009-06-08 Thread Alvaro Herrera
value. I have experimented with other choices such as not rebuilding the database list if the time elapsed since last rebuild is not very long, but there were small problems with that so I'd prefer to avoid it. -- Alvaro Herrerahttp://www.CommandPrompt.com

Re: [PERFORM] autovacuum hung?

2009-05-29 Thread Alvaro Herrera
long? What's vacuum_cost_delay? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http

Re: [PERFORM] Problems with autovacuum

2009-05-26 Thread Alvaro Herrera
to do anything. I believe the interpretation of autovacuum_naptime is that it should examine each database that often, ie once a minute by default. So it's got more than 30 databases per second to look through. Note that this is correct in 8.1 and 8.2 but not 8.3 onwards. -- Alvaro Herrera

Re: [PERFORM] Problems with autovacuum

2009-05-26 Thread Alvaro Herrera
Tom Lane escribió: Alvaro Herrera alvhe...@commandprompt.com writes: Tom Lane escribi�: I believe the interpretation of autovacuum_naptime is that it should examine each database that often, ie once a minute by default. So it's got more than 30 databases per second to look through

Re: [PERFORM] Problems with autovacuum

2009-05-26 Thread Alvaro Herrera
launcher_determine_sleep()). Maybe that needs to be increased? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your

Re: [PERFORM] Problems with autovacuum

2009-05-26 Thread Alvaro Herrera
Tom Lane escribió: Alvaro Herrera alvhe...@commandprompt.com writes: Tom Lane escribi�: Hmm, maybe we need to improve the code too. This example suggests that there needs to be some limit on the worker launch rate, even if there are so many databases that that means we don't meet naptime

Re: [PERFORM] Any better plan for this query?..

2009-05-12 Thread Alvaro Herrera
Andres Freund escribió: Naturally it would still be nice to be good in this not optimal workload... I find it hard to justify wasting our scarce development resources into optimizing such a contrived workload. -- Alvaro Herrerahttp://www.CommandPrompt.com

Re: [PERFORM] Any better plan for this query?..

2009-05-12 Thread Alvaro Herrera
to choose when your client connection will benefit from a fresh backend or an existing one. And it's respecting some backend timeouts etc. Hmm. Seems like the best idea if we go this route would be one of Simon's which was to have better support for pluggable postmaster children. -- Alvaro

Re: [PERFORM] Any better plan for this query?..

2009-05-11 Thread Alvaro Herrera
we simply *reuse* the same plan?.. This has been discussed in the past, but it turns out that a real implementation is a lot harder than it seems. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Re: [PERFORM] Any better plan for this query?..

2009-05-07 Thread Alvaro Herrera
changed little bit a reference key criteria from = '01' to '51', so instead of 20 rows I have 1000 rows on output now, Another thing you can try is run the query several times (like 1 or so). -- Alvaro Herrerahttp://www.CommandPrompt.com

Re: [PERFORM] Transparent table partitioning in future version of PG?

2009-05-06 Thread Alvaro Herrera
there should be a way to refer to individual partitions as objects. That way we could execute some commands to enable certain optimizations, for example mark this partition read only which would mean it could be marked as not needing vacuum. -- Alvaro Herrerahttp

Re: [PERFORM] plpgsql arrays

2009-04-03 Thread Alvaro Herrera
would be interesting indeed. +42 -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription

Re: [PERFORM] Trying to track down weird query stalls

2009-03-30 Thread Alvaro Herrera
from that is bad (and it often is), you should look at avoiding a query prepare. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-performance mailing list (pgsql-performance

Re: [PERFORM] Trying to track down weird query stalls

2009-03-30 Thread Alvaro Herrera
pasted earlier? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http

Re: [PERFORM] Trying to track down weird query stalls

2009-03-30 Thread Alvaro Herrera
in as placeholders) Right, so how about you reread what I wrote above? Oh, hmm, so to be more clear: I don't think DBD::Pg is actually sending EXECUTE PREPARE. You need to do this over psql. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication

Re: [PERFORM] Trying to track down weird query stalls

2009-03-30 Thread Alvaro Herrera
, but double-checking seems prudent. Yes, but I doubt that it'll be smart enough to work for EXPLAIN in the way we need here. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-performance mailing list (pgsql

Re: [PERFORM] Proposal of tunable fix for scalability of 8.4

2009-03-20 Thread Alvaro Herrera
) lock manager, but that's a pretty different body of code. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make

Re: [PERFORM] Need help with one query

2009-03-20 Thread Alvaro Herrera
geqo_threshold set to? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [PERFORM] Proposal of tunable fix for scalability of 8.4

2009-03-20 Thread Alvaro Herrera
Alvaro Herrera escribió: Simon's explanation, however, is at odds with the code. http://git.postgresql.org/?p=postgresql.git;a=blob;f=src/backend/storage/lmgr/lwlock.c There is queue jumping in the regular (heavyweight) lock manager, but that's a pretty different body of code. I'll just

Re: [PERFORM] Proposal of tunable fix for scalability of 8.4

2009-03-20 Thread Alvaro Herrera
Alvaro Herrera escribió: So Simon's correct. And perhaps this explains why Jignesh is measuring an improvement on his benchmark. Perhaps an useful experiment would be to turn this behavior off and compare performance. This lack of measurement is probably the cause that the suggested patch

Re: [PERFORM] Proposal of tunable fix for scalability of 8.4

2009-03-12 Thread Alvaro Herrera
backends, given an avg. response time of ~20ms) Something that might be useful for him to report is the avg number of active backends for each data point ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7

Re: [PERFORM] scheduling autovacuum at lean hours only.

2009-02-11 Thread Alvaro Herrera
Rajesh Kumar Mallah escribió: why is it not a good idea to give end users control over when they want to run it ? It has never been said that we don't want to give the users control. It's a matter of writing the code. If you want to propose a patch to add the feature, feel free. -- Sent via

Re: [PERFORM] Deleting millions of rows

2009-02-03 Thread Alvaro Herrera
yet -- we don't have access to the list of acted-upon tuples. As soon as we have that we can start discussing this optimization. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-performance mailing

Re: [PERFORM] postgresql 8.3 tps rate

2009-01-22 Thread Alvaro Herrera
in the prepare step (-i) at least as high as the number of clients you're going to use. (I dimly recall some recent development in this area that might mean I'm wrong.) -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent

Re: [PERFORM] Poor plan choice in prepared statement

2008-12-31 Thread Alvaro Herrera
until the parameters have been received. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http

Re: [PERFORM] dbt-2 tuning results with postgresql-8.3.5

2008-12-23 Thread Alvaro Herrera
. If you want to track all autovacuum actions, change autovacuum_log_min_messages to 0. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-performance mailing list (pgsql-performance

Re: [PERFORM] [ADMIN] rebellious pg stats collector (reopened case)

2008-12-22 Thread Alvaro Herrera
Laszlo Nagy wrote: %gcc -o test test.c %./test ppid = 47653 ppid = 47653 ppid = 47653 # Started truss -p 48864 here! ppid = 49073 ppid = 49073 ppid = 49073 I think you should report that as a bug to Sun. -- Alvaro Herrerahttp://www.CommandPrompt.com

Re: [PERFORM] Hash join on int takes 8..114 seconds

2008-11-21 Thread Alvaro Herrera
probably, or maybe 10-100 being extremely generous. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes

Re: [PERFORM] Hash join on int takes 8..114 seconds

2008-11-21 Thread Alvaro Herrera
Andrus wrote: Will value of 30 allow other clients to work when VACUUM FULL is running ? 1. vacuum_cost_delay does not affect vacuum full 2. vacuum full is always blocking, regardless of settings So I gather you're not doing any vacuuming, eh? -- Alvaro Herrera

Re: [PERFORM] Hash join on int takes 8..114 seconds

2008-11-21 Thread Alvaro Herrera
(and then to all others, just to be sure) and run vacuum (no full). -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make

Re: [PERFORM] PostgreSQL NOT IN performance

2008-11-19 Thread Alvaro Herrera
on other thing nor on enhancing planner in other ways, like better estimations of known plans). http://wiki.postgresql.org/wiki/Submitting_a_Patch http://wiki.postgresql.org/wiki/Developer_FAQ -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication

Re: [PERFORM] Configuring for maximum memory usage

2008-10-30 Thread Alvaro Herrera
buffers means exactly that the page is cached (a.k.a. it won't have to be read from the lower level next time). -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance

Re: [PERFORM] too many clog files

2008-09-10 Thread Alvaro Herrera
Kevin Grittner escribió: It sounds like the advice to the OP that running VACUUM FREEZE on all databases to clean up the files was off base? His responses are not explicit enough to know. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company

Re: [PERFORM] too many clog files

2008-09-05 Thread Alvaro Herrera
they were, and run VACUUM FREEZE in all your databases. That should clean up all the old pg_clog files, if you're really that desperate. This is not something that I'd recommend doing on a periodic basis ... -- Alvaro Herrerahttp://www.CommandPrompt.com

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

2008-08-29 Thread Alvaro Herrera
[EMAIL PROTECTED] escribió: On Thu, 28 Aug 2008, Alvaro Herrera wrote: [EMAIL PROTECTED] escribi?: On Thu, 28 Aug 2008, Scott Marlowe wrote: scenario 1: There's a postmaster, it owns all the child processes. It gets killed. The Postmaster gets restarted. Since there isn't one when

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

2008-08-28 Thread Alvaro Herrera
. In this scenario, it is both a kernel fault and sysadmin stupidity. The corruption that ensues is 100% deserved. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-performance

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

2008-08-28 Thread Alvaro Herrera
without the children being shutdown first? I would be surprised if that was really true. If the sysadmin sends a SIGKILL then obviously the same thing happens. Any other signal gives it the chance to signal the children before dying. -- Alvaro Herrerahttp

Re: [PERFORM] control the number of clog files and xlog files

2008-08-27 Thread Alvaro Herrera
including the old files are still useful for postgresql? and when will they deleted or rotated? Or should they be deleted and maintained by external programs? Yes, those files are still useful. They will be deleted eventually. -- Alvaro Herrerahttp

Re: [PERFORM] Is there a way to SubPartition?

2008-08-27 Thread Alvaro Herrera
this, but this is an exciting report to read. Not many years ago, this kind of system would have been unthinkable. We've now tuned the system so that people is starting to consider it, and for a lot of people it is working. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL

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

2008-08-27 Thread Alvaro Herrera
(this is an Oracle tweak AFAIK). These are tricks that people could use in their init scripts to protect themselves. (I wonder if the initscript supplied by the RPMs or Debian should contain such a hack.) -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication

Re: [PERFORM] control the number of clog files and xlog files

2008-08-26 Thread Alvaro Herrera
to corrupt your database. - What effect does Deleting the clog and xlogfiles bring about? Will it cause Postgresql abnormal stopping? Your data will be corrupt. It may continue to work for a while, and suddenly stop working at a future time. -- Alvaro Herrerahttp

Re: [PERFORM] Identifying the nature of blocking I/O

2008-08-24 Thread Alvaro Herrera
of DTrace. See here for an article on the topic: http://lwn.net/Articles/291091/ -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make

Re: [PERFORM] The state of PG replication in 2008/Q2?

2008-08-21 Thread Alvaro Herrera
/products/mammothreplicator/ ? It is about to go open source but it doesn't replicate DDL either. It doesn't replicate multiple databases either. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql

Re: [PERFORM] Incorrect estimates on correlated filters

2008-08-13 Thread Alvaro Herrera
after the join. Unfortunately, the planner thinks we will get 1 row back. Maybe you can wrap that part of the query in a SQL function and set its estimated cost to the real values with ALTER FUNCTION ... ROWS. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL

[PERFORM] autovacuum: use case for indenpedent TOAST table autovac settings

2008-08-13 Thread Alvaro Herrera
Hackers and PG users, Does anyone see a need for having TOAST tables be individually configurable for autovacuum? I've finally come around to looking at being able to use ALTER TABLE for autovacuum settings, and I'm wondering if we need to support that case. -- Alvaro Herrera

Re: [HACKERS] [PERFORM] autovacuum: use case for indenpedent TOAST table autovac settings

2008-08-13 Thread Alvaro Herrera
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Does anyone see a need for having TOAST tables be individually configurable for autovacuum? I've finally come around to looking at being able to use ALTER TABLE for autovacuum settings, and I'm wondering if we need to support

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

2008-07-28 Thread Alvaro Herrera
if Pg even has a query result cache - I don't think so, but I'm not sure. It doesn't. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-performance mailing list (pgsql-performance

Re: [PERFORM] how to fix problem then when two queries run at the same time, it takes longer to complete then if run in sequence

2008-07-23 Thread Alvaro Herrera
one connection slot. If the pooler is capable to be configured to block new connections until the slot is unused, this would do what you want. (I don't know whether poolers allow you to do this). -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL

Re: [PERFORM] Mailing list hacked by spammer?

2008-07-18 Thread Alvaro Herrera
that messages from unsubscribed addresses are held up for moderation. A human moderator must then reject it or approve it, and humans make mistakes sometimes. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql

Re: [PERFORM] Altering a column type - Most efficient way

2008-07-11 Thread Alvaro Herrera
it to skip the check and the possible table rewrite in the cases where it's obviously not needed (like this one). -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-performance mailing list (pgsql

Re: [PERFORM] Altering a column type - Most efficient way

2008-07-10 Thread Alvaro Herrera
Ow Mun Heng wrote: This is what I see on the table NEW attypmod = -1 OLD attypmod = 8 8 means varchar(4) which is what you said you had (4+4) -1 means unlimited size. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt

Re: [PERFORM] VACUUM ANALYZE blocking both reads and writes to a table

2008-06-30 Thread Alvaro Herrera
in the balancing code, but it is simpler this way. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes

Re: [PERFORM] VACUUM ANALYZE blocking both reads and writes to a table

2008-06-30 Thread Alvaro Herrera
that causes significant disk I/O and/or scales badly with table size or similar? It is fast. I.e., is this enough that, even without the .4 bug, one should not really consider VACUUM ANALYZE non-blocking with respect to other transactions? You should consider it non-blocking. -- Alvaro

Re: [PERFORM] VACUUM ANALYZE blocking both reads and writes to a table

2008-06-30 Thread Alvaro Herrera
Alvaro Herrera wrote: Peter Schuller wrote: Actually, while on the topic: date: 2007-09-10 13:58:50 -0400; author: alvherre; state: Exp; lines: +6 -2; Remove the vacuum_delay_point call in count_nondeletable_pages, because we hold an exclusive lock

Re: [PERFORM] VACUUM ANALYZE blocking both reads and writes to a table

2008-06-30 Thread Alvaro Herrera
Tom Lane wrote: (2) If it's autovacuum we're talking about, it will get kicked off the table if anyone else comes along and wants a conflicting lock. Not on 8.2 though. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc

Re: [PERFORM] Scalability question

2008-06-11 Thread Alvaro Herrera
multiple transactions. btree and gist indexes can have multiple concurrent insertions in flight. A potential for blocking is in UNIQUE indexes: if two transactions try to insert the same value in the unique index, the second one will block until the first transaction finishes. -- Alvaro Herrera

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

2008-05-16 Thread Alvaro Herrera
to ensure that the pg_clog page that corresponds to it is allocated, but it need not write anything to it. (*) Each transaction needs 2 bits, so on a 8 kB page there is space for 4 transactions/byte * 8 pages * 1kB/page = 32k transactions. -- Alvaro Herrerahttp

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

2008-05-16 Thread Alvaro Herrera
Alvaro Herrera wrote: pg_clog is allocated in pages of 8kB apiece(*). On allocation, pages are zeroed, which is the bit pattern for transaction in progress. So when a transaction starts, it only needs to ensure that the pg_clog page that corresponds to it is allocated, but it need not write

Re: [PERFORM] Please ignore ...

2008-05-16 Thread Alvaro Herrera
address? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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(*)

2008-05-15 Thread Alvaro Herrera
the bitmask in a separate map fork, this could be cheap. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your

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

2008-05-15 Thread Alvaro Herrera
Heikki Linnakangas escribió: Alvaro Herrera wrote: The problem is that the bgwriter does not understand about the content of the pages it is writing -- they're opaque pages for all it knows. So it cannot touch the hint bits. We know what kind of a relation we're dealing with in ReadBuffer

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

2008-05-15 Thread Alvaro Herrera
Matthew Wakeling wrote: Aside from the rest of commentary, a slight clarification: So, as I understand it, Postgres works like this: 1. You begin a transaction. Postgres writes an entry into pg_clog. Starting a transaction does not write anything to pg_clog. -- Alvaro Herrera

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

2008-05-14 Thread Alvaro Herrera
if you find out a permanent state). Regarding FAQs, I'm having trouble imagining putting this in the user FAQ; I think it belongs into the developer's FAQ. However, a benchmarker is not going to look there. Maybe we should start a benchmarker's FAQ? -- Alvaro Herrera

Re: [PERFORM] Please ignore ...

2008-05-02 Thread Alvaro Herrera
Marc G. Fournier wrote: Someone on this list has one of those 'confirm your email' filters on their mailbox, which is bouncing back messages ... this is an attempt to try and narrow down the address that is causing this ... Did you find out? -- Alvaro Herrera

Re: [PERFORM] Replication Syatem

2008-04-29 Thread Alvaro Herrera
Gauri Kanekar escribió: Do we need to do any special config changes or any other setting for HOT to work?? No. HOT is always working, if it can. You don't need to configure it. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command

Re: [PERFORM] Replication Syatem

2008-04-29 Thread Alvaro Herrera
Gauri Kanekar escribió: Found that the size increased gradually. Is HOT working over here ?? Guide me if im doing something wrong. Probably not. Try vacuuming between the updates. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication

Re: [PERFORM] Vacuum settings

2008-04-21 Thread Alvaro Herrera
. In any case, since the other values are all wrong I suggest just setting it to 10ms and seeing what happens). -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-performance mailing list

Re: [PERFORM] Re: [HACKERS] [COMMITTERS] pgsql: Fix TransactionIdIsCurrentTransactionId() to use binary search

2008-04-21 Thread Alvaro Herrera
should poke at it from here. TIA. Perhaps what you could do is backpatch the change and see if the problem goes away. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-performance mailing list (pgsql

Re: [PERFORM] 3-days-long vacuum of 20GB table

2008-04-18 Thread Alvaro Herrera
was rewritten by Heikki Linnakangas to do linear passes for indexes in 8.2 AFAIR. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes

Re: [PERFORM] SQL Function Slowness, 8.3.0

2008-04-17 Thread Alvaro Herrera
and see how hard it is to generate a reverse translation tool from the .po files. That would rock -- I have wished for such a thing (in fact I troll the PO catalogs by hand at times.) -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting

Re: [PERFORM] Creating large database of MD5 hash values

2008-04-11 Thread Alvaro Herrera
, it would be wise to create your own datatype and operators with the most compact and efficient representation possible. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-performance

Re: [PERFORM] Performance with temporary table

2008-04-08 Thread Alvaro Herrera
autovacuum should be at work here (and if not you can solve the issue with manual vacuums to the system catalogs), but even then it is at best unnecessary. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via

Re: [PERFORM] Performance with temporary table

2008-04-08 Thread Alvaro Herrera
also bloat the catalog or hinder the performance? In terms of catalog usage, permanent tables behave exactly the same as temp tables. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via

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

2008-03-27 Thread Alvaro Herrera
table. So, in that case, it can pay (big time actually) to disable toasting, store the data inline, and benefit from cluster. This claim is false -- CLUSTER does process the toast table along the main heap. -- Alvaro Herrerahttp://www.CommandPrompt.com

Re: [PERFORM] postgresql is slow with larger table even it is in RAM

2008-03-25 Thread Alvaro Herrera
involved, there's a lot of work to do. I am not sure if with your hardware it is expected for it to take 3 seconds though. Do you see high CPU usage during that period? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom

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

2008-03-25 Thread Alvaro Herrera
of them all the time. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [PERFORM] question on TRUNCATE vs VACUUM FULL

2008-03-19 Thread Alvaro Herrera
at the table after the VACUUM FULL is completed. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http

Re: [PERFORM] Re: Confirma çã o de envio / Sending confirmation (captchaid:13266b402f09)

2008-03-08 Thread Alvaro Herrera
petchimuthu lingam escribió: VQQ7HE18 Please stop sending this nonsense. These sending confirmations are not necessary -- they are sent by a clueless user whose identity we've as of yet unable to determine (otherwise we would have kicked him from the list.) -- Alvaro Herrera

Re: [PERFORM] Toast space grows

2008-03-07 Thread Alvaro Herrera
from your application after insert and update operations. I perform autovacuum daily. Sorry, this sentence makes no sense. Do you mean that you set autovacuum_naptime=1 day? If so, that's a bad idea -- you should let autovacuum run far more frequently. -- Alvaro Herrera

Re: [PERFORM] count * performance issue

2008-03-06 Thread Alvaro Herrera
/static/release-8-2.html http://www.postgresql.org/docs/8.3/static/release-8-1.html http://www.postgresql.org/docs/8.3/static/release-8-0.html which are all the major releases between 7.4 and 8.3. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company

Re: [PERFORM] strange pauses

2008-01-18 Thread Alvaro Herrera
. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [PERFORM] Best way to index IP data?

2008-01-11 Thread Alvaro Herrera
this means is that our type oughta be optimized. How about having a separate bit to indicate whether there is a netmask or not, and chop the storage earlier. (I dunno if this already done) Also, with packed varlenas the overhead is reduced AFAIK. -- Alvaro Herrera

Re: [PERFORM] After Vacuum Analyse - Procedure performance not improved - Innner select is faster

2008-01-08 Thread Alvaro Herrera
EXECUTE in the function. But most likely this is just a one-time problem. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP

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

2008-01-07 Thread Alvaro Herrera
0x2b005cf6f110 in killpg () from /lib/libc.so.6 #8 0x in ?? () Perhaps it would make sense to try to take the fast path in SIDelExpiredDataEntries with only a shared lock rather than exclusive. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL

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

2008-01-03 Thread Alvaro Herrera
Jakub Ouhrabka wrote: - do an UNLISTEN if possible Yes, we're issuing unlistens when appropriate. You are vacuuming pg_listener periodically, yes? Not that this seems to have any relationship to your problem, but ... -- Alvaro Herrerahttp

Re: [PERFORM] More shared buffers causes lower performances

2007-12-27 Thread Alvaro Herrera
. Maybe we ought to put that more strongly --- s/a little/significantly/, perhaps? I don't think it will make any difference, because people don't read configure documentation. They read configure --help. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL

Re: [PERFORM] More shared buffers causes lower performances

2007-12-27 Thread Alvaro Herrera
packages that are built with --enable-cassert perhaps need to be labeled as not intended for benchmarking or some such. Perhaps make them emit a WARNING at server start or something. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication

Re: [PERFORM] Reinitialising stats once only without restarting

2007-12-20 Thread Alvaro Herrera
pg_stat_reset(); -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings

Re: [PERFORM] viewing source code

2007-12-20 Thread Alvaro Herrera
access to this function.) -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [PERFORM] viewing source code

2007-12-20 Thread Alvaro Herrera
that. Also, having an encrypted source code means there must be a decryption key somewhere, which is a pain on itself. And if you expose the crypted prosrc, you are exposing to brute force attacks (to which you are not if prosrc is hidden). -- Alvaro Herrerahttp

Re: [PERFORM] viewing source code

2007-12-20 Thread Alvaro Herrera
to note that I would probably not be the one to actually produce a patch in this direction, or even to work on a working, detailed design :-) You just read Joshua's opinion on this issue and I don't think I need to say more :-) -- Alvaro Herrerahttp

Re: [PERFORM] viewing source code

2007-12-18 Thread Alvaro Herrera
Roberts, Jon escribió: Revoking pg_proc isn't good for users that shouldn't see other's code but still need to be able to see their own code. So create a view on top of pg_proc restricted by current role, and grant select on that to users. -- Alvaro Herrera

Re: [PERFORM] viewing source code

2007-12-18 Thread Alvaro Herrera
; with backend changes it is certainly doable (for example invent a separate view source privilege for functions). -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast

Re: [PERFORM] viewing source code

2007-12-14 Thread Alvaro Herrera
. Maybe this can be done by revoking privileges to pg_proc. I am sure it can be made to work. It does work for pg_auth_id, and nobody says that they can read the passwords from disk anyway. -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ We're here to devour each

Re: [PERFORM] viewing source code

2007-12-14 Thread Alvaro Herrera
Roberts, Jon escribió: I'm not familiar at all with pg_read_file. Is it wide open so a user can read any file they want? Can you not lock it down like utl_file and directories in Oracle? That function is restricted to superusers. -- Alvaro Herrera Developer, http

Re: [PERFORM] Heavy write activity on first vacuum of fresh TOAST data

2007-12-13 Thread Alvaro Herrera
, pages are opaque. -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC There is evil in the world. There are dark, awful things. Occasionally, we get a glimpse of them. But there are dark corners; horrors almost impossible to imagine... even in our worst nightmares. (Van

Re: [PERFORM] Putting files into fields in a table

2007-12-13 Thread Alvaro Herrera
Campbell, Lance wrote: I did not see much info in the 8.2 documentation on BLOB. That's because we don't call them blobs. Search for large objects instead: http://www.postgresql.org/docs/current/static/largeobjects.html -- Alvaro Herrera http://www.flickr.com/photos

Re: [PERFORM] libgcc double-free, backend won't die

2007-12-11 Thread Alvaro Herrera
*** postgres: mydb mydb [local] idle: double free or corruption! (!prev): 0x08bfcde8 Do you have any Perl or Python functions or stuff like that? Postgres 8.1.4 Please upgrade to 8.1.10 and try again. If it still fails we will be much more interested in tracking it down. -- Alvaro Herrera

<    1   2   3   4   5   >