Re: [HACKERS] Annotated release notes
On Thu, Oct 30, 2003 at 11:59:05PM -0500, Bruce Momjian wrote: OK, I have committed changes to release.sgml so most complex entries have a paragraph describing the change. You can see the result at: * Full support for IPv6 connections and IPv6 address data types Prior releases allowed only IPv6 connections and IP data types only supported IPv4 addresses. This release adds full IPv6 support in both of these areas. You probably want to say Prior releases allowed only IPv4 connections. Kurt ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Annotated release notes
Kurt Roeckx wrote: On Thu, Oct 30, 2003 at 11:59:05PM -0500, Bruce Momjian wrote: OK, I have committed changes to release.sgml so most complex entries have a paragraph describing the change. You can see the result at: * Full support for IPv6 connections and IPv6 address data types Prior releases allowed only IPv6 connections and IP data types only supported IPv4 addresses. This release adds full IPv6 support in both of these areas. You probably want to say Prior releases allowed only IPv4 connections. Fixed. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [DOCS] Annotated release notes
Joe Conway wrote:
Bruce Momjian wrote:
http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-7-4
I need people to check this and help me with the items marked 'bjm'. I
am confused about the proper text for those sections.
Allow polymorphic SQL functions (Joe)
bjm ??
What isn't clear about this? Should/can we refer to related sections of
the manual?
http://developer.postgresql.org/docs/postgres/xfunc-sql.html#AEN28722
http://developer.postgresql.org/docs/postgres/extend-type-system.html#EXTEND-TYPES-POLYMORPHIC
Allow user defined aggregates to use polymorphic functions (Joe)
bjm ??
Same question. From this url:
http://developer.postgresql.org/docs/postgres/xaggr.html
see this paragraph:
Aggregate functions may use polymorphic state transition functions or
final functions, so that the same functions can be used to implement
multiple aggregates. See Section 33.2.1 for an explanation of
polymorphic functions. Going a step further, the aggregate function
itself may be specified with a polymorphic base type and state type,
allowing a single aggregate definition to serve for multiple input data
types. Here is an example of a polymorphic aggregate:
CREATE AGGREGATE array_accum (
sfunc = array_append,
basetype = anyelement,
stype = anyarray,
initcond = '{}'
);
What had me really confused was the first release item:
Allow polymorphic SQL functions (Joe)
How does an SQL function query the data types passed to it? Once I saw
that I thought I didn't underestand what polymorphic functions were.
Right now we have:
listitemparaAllow user defined aggregates to use polymorphic functions
(Joe)/para
para
bjm ??
/para
/listitem
listitemparaAllow polymorphic user defined aggregates
(Joe)/para/listitem
These seem like duplicates. Are polymorphic functions currently most
useful for aggregates? Why would someone want polymorphic aggregates?
That is what I was hoping for.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [DOCS] Annotated release notes
Bruce Momjian wrote:
What had me really confused was the first release item:
Allow polymorphic SQL functions (Joe)
How does an SQL function query the data types passed to it? Once I
saw that I thought I didn't underestand what polymorphic functions
were.
It doesn't need to. For example:
CREATE OR REPLACE FUNCTION makearray(anyelement, anyelement) returns
anyarray as 'select ARRAY[$1, $2]' language sql;
regression=# select makearray(1,2);
makearray
---
{1,2}
(1 row)
regression=# select makearray('a'::text,'b');
makearray
---
{a,b}
(1 row)
listitemparaAllow user defined aggregates to use polymorphic
functions (Joe)/para listitemparaAllow polymorphic user defined
aggregates (Joe)/para/listitem
These seem like duplicates.
They aren't. The first says you could create an aggregate with defined
base and state datatypes, but where the state/final functions might be
polymorphic. The second says that the base and state types might be
polymorphic.
Are polymorphic functions currently most useful for aggregates? Why
would someone want polymorphic aggregates? That is what I was hoping
for.
Well, one example is a calculation aggregate (let's say median) which
you might want to use for any numeric data type. Or an array
accumulator, e.g.
CREATE AGGREGATE myagg1
(
BASETYPE = float8,
SFUNC = array_append,
STYPE = float8[],
INITCOND = '{}'
);
CREATE AGGREGATE
CREATE AGGREGATE myagg1p
(
BASETYPE = anyelement,
SFUNC = array_append,
STYPE = anyarray,
INITCOND = '{}'
);
CREATE AGGREGATE
Joe
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] 7.4 and 7.3.5 showstopper (was: Re: [SQL] Bug in Rule+Foreing
On Thu, 2003-10-30 at 20:13, Jan Wieck wrote: Thanks for reporting, Michele. Thank to you! The speed and level of your responses exceeds every my more rose-colored expectation ;-) In the meantime, you might want to use a BEFORE INSERT trigger in PL/pgSQL that tries to UPDATE the row and if GET DIAGNOSTICS tells it it succeeded, returns NULL to suppress the INSERT. That should work around the bug for the time being. It is not a problem for me, the db is not still in production, so I think i wait for the patch. Thank to all you again. ciao, Michele ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for port reports
Bruce Momjian writes:
It is time for people to report their port testing. Please test against
current CVS or beta5 and report your 'uname -a'.
For a change, here is one that does not work:
HP-UX hpunix5 B.11.00 U 9000/803 2002765023
Using the system compiler, I get several complaints about our use of
inline, for example:
cc -Ae +O2 -I../../../../src/include -D_XOPEN_SOURCE_EXTENDED -c -o dynahash.o
dynahash.c
cc: dynahash.c, line 466: error 1000: Unexpected symbol: calc_bucket.
cc: panic 2017: Cannot recover from earlier errors, terminating.
I had to patch it as follows to get it to work:
diff -ur ../cvs-pgsql/src/backend/utils/hash/dynahash.c
./src/backend/utils/hash/dynahash.c
--- ../cvs-pgsql/src/backend/utils/hash/dynahash.c 2003-08-19 03:13:41.0
+0200
+++ ./src/backend/utils/hash/dynahash.c 2003-10-31 11:05:05.0 +0100
@@ -462,7 +462,7 @@
/* Convert a hash value to a bucket number */
-static inline uint32
+static uint32
calc_bucket(HASHHDR *hctl, uint32 hash_val)
{
uint32 bucket;
diff -ur ../cvs-pgsql/src/backend/utils/sort/tuplesort.c
./src/backend/utils/sort/tuplesort.c
--- ../cvs-pgsql/src/backend/utils/sort/tuplesort.c 2003-08-17 21:58:06.0
+0200
+++ ./src/backend/utils/sort/tuplesort.c2003-10-31 11:10:12.0 +0100
@@ -1784,7 +1784,7 @@
/*
* Inline-able copy of FunctionCall2() to save some cycles in sorting.
*/
-static inline Datum
+static Datum
myFunctionCall2(FmgrInfo *flinfo, Datum arg1, Datum arg2)
{
FunctionCallInfoData fcinfo;
@@ -1816,7 +1816,7 @@
* and return a 3-way comparison result. This takes care of handling
* NULLs and sort ordering direction properly.
*/
-static inline int32
+static int32
inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,
Datum datum1, bool isNull1,
Datum datum2, bool isNull2)
Any ideas?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Rule regression failure freebsd?
Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: See attached regression.diffs. Looks like Jan forgot to update this expected file to match his changes. regards, tom lane Not exactly, I didn't run the parallel regression test and thus missed that rules and foreign_key are in the same group and that the execution of the latter now affects the result of the former. I'll try to fix it by moving the test into rule.sql (it's placed there as wrong as it's in foreign_key). If that doesn't work either I will back it out as we don't want bigger regression test rearrangements at this stage in the release cycle. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] static pg_dump
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Is there any way we could build a static version of the 7.4 pg_dump, to make it easy to dump existing databases using the 7.4 dump? Otherwise, it's quite difficult to arrange to have two different postgres installations, etc... Why? There should be no problem installing both 7.3 and 7.4 libpq.so --- if they don't have different version numbers, something's wrong. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Rule regression failure freebsd?
Jan Wieck wrote: Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: See attached regression.diffs. Looks like Jan forgot to update this expected file to match his changes. regards, tom lane Not exactly, I didn't run the parallel regression test and thus missed that rules and foreign_key are in the same group and that the execution of the latter now affects the result of the former. I'll try to fix it by moving the test into rule.sql (it's placed there as wrong as it's in foreign_key). If that doesn't work either I will back it out as we don't want bigger regression test rearrangements at this stage in the release cycle. The test is now in rule.sql. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for port reports
Peter Eisentraut [EMAIL PROTECTED] writes: HP-UX hpunix5 B.11.00 U 9000/803 2002765023 Using the system compiler, I get several complaints about our use of inline, for example: Interesting. CVS tip works fine for me on HPUX 10.20, using cc -Ae. It looks like configure deduces inline is not supported on this compiler, though: /* Define as `__inline' if that's what the C compiler calls it, or to nothing if it is not supported. */ #define inline What do you get on that compiler? I had to patch it as follows to get it to work: Odd. I count ten inline functions in the backend: src/backend/storage/lmgr/lock.c: 94: inline static bool src/backend/storage/lmgr/lock.c: 105: inline static void src/backend/storage/lmgr/lock.c: 126: inline static void src/backend/storage/lmgr/lwlock.c: 67: inline static void src/backend/storage/lmgr/lwlock.c: 77: inline static void src/backend/utils/adt/pg_lzcompress.c: 389: static inline int src/backend/utils/hash/dynahash.c: 465: static inline uint32 src/backend/utils/mmgr/aset.c: 256: static inline int src/backend/utils/sort/tuplesort.c: 1787: static inline Datum src/backend/utils/sort/tuplesort.c: 1819: static inline int32 Why would only three of them fail? I'm not eager to remove the inlining optimization for everyone just because this one compiler fails. I think a more reasonable approach would be to force inline to be #define'd as empty on that platform. Or file a bug report with HP. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Call for port reports
Bruce Momjian [EMAIL PROTECTED] writes: It is time for people to report their port testing. Please test against current CVS or beta5 and report your 'uname -a'. I can confirm CVS tip on HPUX 10.20, using both gcc and vendor's cc. $ uname -a HP-UX sss2 B.10.20 C 9000/780 2004473515 32-user license Looks like there are already confirmations for the other platforms I have at hand ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for port reports
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
One other idea would be to set CFLAGS to before including template,
and just test to see if it is still after --- that might be cleaner
than saving the original value and comparing.
Yeah, that bothered me a bit too --- what if the template tries to set
CFLAGS to its already-existing value? I was thinking that unsetting
CFLAGS before running the template would be the best answer.
I assume he did it that way so if you do:
CFLAGS=
in the template file that it would be honored. I see lots of this in
configure:
ac_env_CFLAGS_set=${CFLAGS+set}
but that uses 'set' if the variable is null or unset:
${parameter:+word}
Use Alternate Value. If parameter is null or
unset, nothing is substituted, otherwise the expan-
sion of word is substituted.
However, I thought null meant , but I now think null basically means
the same as unset in this manual page. Notice that '+' tests only for
unset, and knows when you have done VAR= and VAR=:
$ echo ${Y+no}
$ Y=
$ echo ${Y+no}
no
$ Y=
$ echo ${Y+no}
no
$ unset Y
$ echo ${Y+no}
$
so the proper test would be to unset the variable, then use ${var+val}
to test CFLAGS after the template file is included.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.4RC1 planned for Monday
Christopher Kings-Lynne wrote: Does anyone have anything ready to put into CVS as soon as we start v7.5, or shortly afterwards? Check bruce's 7.5 patches list (can't remember the address though :) ) I have this COMMENT ON thing ready to go, except for this darn taking in unsigned ints from the parser business that I haven't had any suggests for :P URL is: http:/momjian.postgresql.org/cgi-bin/pgpatches2 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] static pg_dump
Tom Lane [EMAIL PROTECTED] writes: Christopher Kings-Lynne [EMAIL PROTECTED] writes: Is there any way we could build a static version of the 7.4 pg_dump, to make it easy to dump existing databases using the 7.4 dump? Otherwise, it's quite difficult to arrange to have two different postgres installations, etc... Why? There should be no problem installing both 7.3 and 7.4 libpq.so --- if they don't have different version numbers, something's wrong. libpq? I thought only the minor version number changed. On linux that means you can only usefully have one installed at once, the older one would never be used. I think on other OSes the older one might be used sometimes. In any case, can't 7.3 pg_dump use the 7.4 libpq? If not then the major version should be bumped. -- greg ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Call for port reports
Tom Lane writes: Odd. I count ten inline functions in the backend: Why would only three of them fail? I just remembered this Autoconf change: 2002-03-28 Kevin Ryde [EMAIL PROTECTED] * lib/autoconf/c.m4 (AC_C_INLINE): Test with a typedef return value, to avoid versions of HP C which don't allow that. So there you have it. Do we want to backpatch the new autoconf test, or define inline to empty for this particular version of this platform, or try to do without typedef'd types? I prefer option 1. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Experimental patch for inter-page delay in VACUUM
Tom Lane wrote: Matthew T. O'Connor [EMAIL PROTECTED] writes: Tom Lane wrote: 2. I only bothered to insert delays in the processing loops of plain VACUUM and btree index cleanup. VACUUM FULL and cleanup of non-btree indexes aren't done yet. I thought we didn't want the delay in vacuum full since it locks things down, we want vacuum full to finish ASAP. As opposed to normal vacuum which would be fired by the autovacuum daemon. My thought was that it'd be up to the user to set vacuum_page_delay appropriately for what he is doing. It might or might not ever make sense to use a nonzero delay in VACUUM FULL, but the facility should be there. (Since plain and full VACUUM share the same index cleanup code, it would take some klugery to implement a policy of no delays for VACUUM FULL anyway.) Best practice would likely be to leave the default vacuum_page_delay at zero, and have the autovacuum daemon set a nonzero value for vacuums it issues. What is the advantage of delaying vacuum per page vs. just doing vacuum less frequently? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Call for port reports
Peter Eisentraut [EMAIL PROTECTED] writes: * lib/autoconf/c.m4 (AC_C_INLINE): Test with a typedef return value, to avoid versions of HP C which don't allow that. So there you have it. Do we want to backpatch the new autoconf test, or define inline to empty for this particular version of this platform, or try to do without typedef'd types? I prefer option 1. Me too, if the patch isn't too big. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 7.4RC1 planned for Monday
Stephan Szabo wrote: On Thu, 30 Oct 2003, Tom Lane wrote: Stephan Szabo [EMAIL PROTECTED] writes: On Thu, 30 Oct 2003, Tom Lane wrote: rule/foreign key interaction reported by Michele Bendazzoli In the interests of disclosure, if the case in question for the rule fails, almost certainly deferred fk constraints will as well which I think makes this a must fix for 7.4 and is another push to getting a 7.3.5. Hm, does Jan's just-committed fix address the concern you had? Head now passes the case I'd thought of: create table ta1(a int primary key); create table ta2(a int references ta1 initially deferred); begin; insert into ta2 values (3); update ta2 set a=3 where a=3; -- should error, but might not if the update isn't checked end; That is basically the same what happened due to Michele's rule. Deferring of the constraint was done there implicitly since both queries resulted from the same statement through rule expansion and the update touched the just inserted row. HEAD and REL7_3_STABLE are safe against this now. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Experimental patch for inter-page delay in VACUUM
Bruce Momjian [EMAIL PROTECTED] writes: What is the advantage of delaying vacuum per page vs. just doing vacuum less frequently? The point is the amount of load VACUUM poses while it's running. If your setup doesn't have a lot of disk bandwidth to spare, a background VACUUM can hurt the performance of your foreground applications quite a bit. Running it less often doesn't improve this issue at all. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PQunescapeBytea code
Jeroen T. Vermeulen [EMAIL PROTECTED] writes: This code completely ignores any other usage of the backslash in the escaped string, generating no output for unknown escape sequences. Is that the desired behaviour? As Adam pointed out, the code does do the right thing for other backslash sequences; it just processes the character on the following loop iteration. I'll add a comment to explain this. I see another issue here, which is that for a zero-length input string we will do malloc(0) and realloc(foo, 0), neither of which are very portable. Will fix. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Experimental patch for inter-page delay in VACUUM
Bruce Momjian wrote: Tom Lane wrote: Matthew T. O'Connor [EMAIL PROTECTED] writes: Tom Lane wrote: 2. I only bothered to insert delays in the processing loops of plain VACUUM and btree index cleanup. VACUUM FULL and cleanup of non-btree indexes aren't done yet. I thought we didn't want the delay in vacuum full since it locks things down, we want vacuum full to finish ASAP. As opposed to normal vacuum which would be fired by the autovacuum daemon. My thought was that it'd be up to the user to set vacuum_page_delay appropriately for what he is doing. It might or might not ever make sense to use a nonzero delay in VACUUM FULL, but the facility should be there. (Since plain and full VACUUM share the same index cleanup code, it would take some klugery to implement a policy of no delays for VACUUM FULL anyway.) Best practice would likely be to leave the default vacuum_page_delay at zero, and have the autovacuum daemon set a nonzero value for vacuums it issues. What is the advantage of delaying vacuum per page vs. just doing vacuum less frequently? It gives regular backends more time to retouch the pages they actually need before they fall off the end of the LRU list. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.4RC1 planned for Monday
On Fri, 31 Oct 2003, Jan Wieck wrote: Stephan Szabo wrote: On Thu, 30 Oct 2003, Tom Lane wrote: Stephan Szabo [EMAIL PROTECTED] writes: On Thu, 30 Oct 2003, Tom Lane wrote: rule/foreign key interaction reported by Michele Bendazzoli In the interests of disclosure, if the case in question for the rule fails, almost certainly deferred fk constraints will as well which I think makes this a must fix for 7.4 and is another push to getting a 7.3.5. Hm, does Jan's just-committed fix address the concern you had? Head now passes the case I'd thought of: create table ta1(a int primary key); create table ta2(a int references ta1 initially deferred); begin; insert into ta2 values (3); update ta2 set a=3 where a=3; -- should error, but might not if the update isn't checked end; That is basically the same what happened due to Michele's rule. Deferring of the constraint was done there implicitly since both queries resulted from the same statement through rule expansion and the update touched the just inserted row. HEAD and REL7_3_STABLE are safe against this now. Yeah. I was worried that it might not carry as much weight especially towards 7.3 if it was thought to be an odd rule/key interaction rather than something that can happen very simply with a deferred constraint. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Experimental patch for inter-page delay in VACUUM
[EMAIL PROTECTED] (Bruce Momjian) writes: Tom Lane wrote: Best practice would likely be to leave the default vacuum_page_delay at zero, and have the autovacuum daemon set a nonzero value for vacuums it issues. What is the advantage of delaying vacuum per page vs. just doing vacuum less frequently? If the vacuum is deferred, that merely means that you put off the slow to a crawl until a bit later. It is a given that the system will slow to a crawl for the duration of the vacuum; you are merely putting it off a bit. The advantage of the per-page delay is that performance is not being totally hammered by the vacuum. If things are so busy that it's an issue, the system is liable to limp somewhat, but that's not as bad as what we see now, where VACUUM and other activity are 'dueling' for access to I/O. Per-page delay means that VACUUM mostly defers to the other activity, limiting how badly it hurts other performance. -- output = reverse(ofni.smrytrebil @ enworbbc) http://dev6.int.libertyrms.com/ Christopher Browne (416) 646 3304 x124 (land) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 7.4RC1 planned for Monday
On Thu, 30 Oct 2003, Joshua D. Drake wrote: If I understood correctly, Josh was complaining about VACUUM sucking too much of his disk bandwidth. autovacuum wouldn't help that --- in fact would likely make it worse, since a cron-driven vacuum script can at least be scheduled for low-load times of day. autovacuum is likely to kick in at the least convenient times. Exactly! Wait a minute, I thought the problem was that vacuums were happening too far apart, therefore taking too long, and may have been full, no? If the autovacuum daemon causes a lazy vacuum to run on only the busiest (i.e. most updated) tables, then it is likely to only take a few minutes to run, instead of hours, plus you can try to keep things steady state. I.e. no more than x% or so dead tuples in a table at any given time, and they all get reused by fsm / lazy vacuum. So, have you TESTED the autovacuum daemon with your load, and set it to run every 5 minutes? Keep in mind, it won't actually vacuum every table every 5 minutes, it'll just check the stats to see which ones have updated a fair bit and vacuum those, and they're lazy vacuums. I've found it to be a win. If you haven't tested it and dismissed it out of hand, then you should really give it a try to see if it can be configured to provide good performance and behavior. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Experimental patch for inter-page delay in VACUUM
Great! I haven't tried it yet, but I love the thought of it already :-) I've been waiting for something like this for the past 2 years and now it's going to make my multi-gigabyte PostgreSQL more usable and responsive. Will the delay be tunable per VACUUM invocation? This is needed for different tables that require different VACUUM priorities (eg. For small tables that are rarely used, I rather vacuum with zero delay. For big tables, I'd set a reasonable delay in vacuum and let it run through the day nite). Regards, Stephen Tom Lane [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Matthew T. O'Connor [EMAIL PROTECTED] writes: Tom Lane wrote: 2. I only bothered to insert delays in the processing loops of plain VACUUM and btree index cleanup. VACUUM FULL and cleanup of non-btree indexes aren't done yet. I thought we didn't want the delay in vacuum full since it locks things down, we want vacuum full to finish ASAP. As opposed to normal vacuum which would be fired by the autovacuum daemon. My thought was that it'd be up to the user to set vacuum_page_delay appropriately for what he is doing. It might or might not ever make sense to use a nonzero delay in VACUUM FULL, but the facility should be there. (Since plain and full VACUUM share the same index cleanup code, it would take some klugery to implement a policy of no delays for VACUUM FULL anyway.) Best practice would likely be to leave the default vacuum_page_delay at zero, and have the autovacuum daemon set a nonzero value for vacuums it issues. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] static pg_dump
Greg Stark wrote: Tom Lane [EMAIL PROTECTED] writes: Christopher Kings-Lynne [EMAIL PROTECTED] writes: Is there any way we could build a static version of the 7.4 pg_dump, to make it easy to dump existing databases using the 7.4 dump? Otherwise, it's quite difficult to arrange to have two different postgres installations, etc... Why? There should be no problem installing both 7.3 and 7.4 libpq.so --- if they don't have different version numbers, something's wrong. libpq? I thought only the minor version number changed. On linux that means you can only usefully have one installed at once, the older one would never be used. I think on other OSes the older one might be used sometimes. In any case, can't 7.3 pg_dump use the 7.4 libpq? If not then the major version should be bumped. 7.4 pg_dump should be able to use 7.3's libpq --- the API has not changed, so we didn't bump the major number. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Regression Failure: CURRENT SOURCES/unionjoin
Here ya go: test union... FAILED test case ... ok test join ... FAILED *** ./expected/union.outThu Oct 9 20:49:31 2003 --- ./results/union.out Fri Oct 31 15:15:50 2003 *** *** 106,112 two - 1.1 !2 (2 rows) SELECT 1.1 AS three UNION SELECT 2 UNION ALL SELECT 2; --- 106,112 two - 1.1 ! 2.0 (2 rows) SELECT 1.1 AS three UNION SELECT 2 UNION ALL SELECT 2; == *** ./expected/join.out Thu Oct 9 20:49:31 2003 --- ./results/join.out Fri Oct 31 15:15:51 2003 *** *** 1732,1739 | 6 | 6 | six | | 7 | 7 | seven | | 8 | 8 | eight | - | | | null | | | 0 | zero | (13 rows) SELECT '' AS xxx, * --- 1732,1739 | 6 | 6 | six | | 7 | 7 | seven | | 8 | 8 | eight | | | 0 | zero | + | | | null | (13 rows) SELECT '' AS xxx, * *** *** 1752,1759 | 6 | 6 | six | | 7 | 7 | seven | | 8 | 8 | eight | - | | | null | | | 0 | zero | (13 rows) SELECT '' AS xxx, * --- 1752,1759 | 6 | 6 | six | | 7 | 7 | seven | | 8 | 8 | eight | | | 0 | zero | + | | | null | (13 rows) SELECT '' AS xxx, * *** *** 1793,1800 -+---+---+---+ | 0 | | zero | | 1 | 4 | one | -1 - | 2 | 3 | two | 2 | 2 | 3 | two | 4 | 3 | 2 | three | -3 | 4 | 1 | four | | 5 | 0 | five | -5 --- 1793,1800 -+---+---+---+ | 0 | | zero | | 1 | 4 | one | -1 | 2 | 3 | two | 4 + | 2 | 3 | two | 2 | 3 | 2 | three | -3 | 4 | 1 | four | | 5 | 0 | five | -5 *** *** 1815,1822 -+---+---+---+ | 0 | | zero | | 1 | 4 | one | -1 - | 2 | 3 | two | 2 | 2 | 3 | two | 4 | 3 | 2 | three | -3 | 4 | 1 | four | | 5 | 0 | five | -5 --- 1815,1822 -+---+---+---+ | 0 | | zero | | 1 | 4 | one | -1 | 2 | 3 | two | 4 + | 2 | 3 | two | 2 | 3 | 2 | three | -3 | 4 | 1 | four | | 5 | 0 | five | -5 == -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] Call for port reports -- Failure on Linux
Did we ever find the cause of this failure? --- Rod Taylor wrote: -- Start of PGP signed section. Linux ns2 2.4.20-xfs #2 Tue Apr 15 10:04:43 EDT 2003 i686 unknown -- SNIP -- stats... FAILED == shutting down postmaster == === 1 of 93 tests failed. === *** ./expected/stats.outSat Sep 13 12:44:48 2003 --- ./results/stats.out Fri Oct 24 14:26:56 2003 *** *** 8,14 SHOW stats_start_collector; -- must be on stats_start_collector --- ! on (1 row) -- save counters --- 8,14 SHOW stats_start_collector; -- must be on stats_start_collector --- ! off (1 row) -- save counters *** *** 62,68 WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? | ?column? | ?column? --+--+--+-- ! t| t| t| t (1 row) SELECT st.heap_blks_read + st.heap_blks_hit = pr.heap_blks + cl.relpages, --- 62,68 WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? | ?column? | ?column? --+--+--+-- ! f| f| f| f (1 row) SELECT st.heap_blks_read + st.heap_blks_hit = pr.heap_blks + cl.relpages, *** *** 71,77 WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? --+-- ! t| t (1 row) -- clean up --- 71,77 WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? --+-- ! f| f (1 row) -- clean up On Fri, 2003-10-24 at 11:37, Bruce Momjian wrote: It is time for people to report their port testing. Please test against current CVS or beta5 and report your 'uname -a'. The current list is at: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html -- End of PGP section, PGP failed! -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] static pg_dump
Bruce Momjian [EMAIL PROTECTED] writes: 7.4 pg_dump should be able to use 7.3's libpq --- the API has not changed, so we didn't bump the major number. No, the other way 'round. 7.3 pg_dump or psql would work with a 7.4 libpq.so, but I don't believe 7.4 pg_dump or psql would work with a 7.3 libpq.so. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Regression Failure: CURRENT SOURCES/unionjoin
Larry Rosenman [EMAIL PROTECTED] writes: *** ./expected/union.out Thu Oct 9 20:49:31 2003 --- ./results/union.out Fri Oct 31 15:15:50 2003 *** *** 106,112 two - 1.1 !2 (2 rows) SELECT 1.1 AS three UNION SELECT 2 UNION ALL SELECT 2; --- 106,112 two - 1.1 ! 2.0 (2 rows) I think this is just a platform-specific difference in the behavior of qsort(). Numeric 2 and 2.0 print differently, but they are equal according to the comparison operators, so it's mostly luck of the draw which one is selected for output. The original coding of this regression test expected that these values would be interpreted as float8, wherein there is no difference between 2 and 2.0. I'm kind of inclined to change the test back to using float8 so we don't see more of these reports. *** ./expected/join.out Thu Oct 9 20:49:31 2003 --- ./results/join.outFri Oct 31 15:15:51 2003 [ row ordering differences ] This also looks like platform-specific behavior --- the differences are in the sort ordering of rows with equal keys. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] out of date bufmgr README
While reading through src/backend/storage/buffer/README, I noticed that the following text seems to no longer be correct: As of 7.1, the only operation that removes tuples or compacts free space is (oldstyle) VACUUM. It does not have to implement rule #5 directly, because it instead acquires exclusive lock at the relation level, which ensures indirectly that no one else is accessing pages of the relation at all. To implement concurrent VACUUM we will need to make it obey rule #5 fully. To do this, we'll create a new buffer manager operation LockBufferForCleanup() that gets an exclusive lock and then checks to see if the shared pin count is currently 1. If not, it releases the exclusive lock (but not the caller's pin) and waits until signaled by another backend, whereupon it tries again. The signal will occur when UnpinBuffer decrements the shared pin count to 1. As indicated above, this operation might have to wait a good while before it acquires lock, but that shouldn't matter much for concurrent VACUUM. The current implementation only supports a single waiter for pin-count-1 on any particular shared buffer. This is enough for VACUUM's use, since we don't allow multiple VACUUMs concurrently on a single relation anyway. Could someone who's aware of the bufmgr changes made for 7.2's lazy VACUUM comment on how this should be updated? -Neil ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] 7.4RC1 planned for Monday
[EMAIL PROTECTED] (scott.marlowe) writes: On Thu, 30 Oct 2003, Joshua D. Drake wrote: If I understood correctly, Josh was complaining about VACUUM sucking too much of his disk bandwidth. autovacuum wouldn't help that --- in fact would likely make it worse, since a cron-driven vacuum script can at least be scheduled for low-load times of day. autovacuum is likely to kick in at the least convenient times. Exactly! Wait a minute, I thought the problem was that vacuums were happening too far apart, therefore taking too long, and may have been full, no? No, that is a different issue. If the autovacuum daemon causes a lazy vacuum to run on only the busiest (i.e. most updated) tables, then it is likely to only take a few minutes to run, instead of hours, plus you can try to keep things steady state. I.e. no more than x% or so dead tuples in a table at any given time, and they all get reused by fsm / lazy vacuum. That is fine, for a system that isn't already pretty much pegged with transaction load. The disk bandwidth problem occurs when the system is already so busy that doing a VACUUM on a big table adds a huge I/O load, killing cache, and slowing the other activity. So, have you TESTED the autovacuum daemon with your load, and set it to run every 5 minutes? Keep in mind, it won't actually vacuum every table every 5 minutes, it'll just check the stats to see which ones have updated a fair bit and vacuum those, and they're lazy vacuums. I've found it to be a win. If you haven't tested it and dismissed it out of hand, then you should really give it a try to see if it can be configured to provide good performance and behavior. If the I/O bus is saturated, and you are doing a lot of updates to big tables, then the vacuums _are_ performance killers. The result of running pg_autovacuum on those tables would be that there would be a near-continuous system slowdown. Not a win. Two things are prime causes for this: 1. VACUUM rips through the page cache, loading the pages of tables being vacuumed, and throwing away other data being frequently accessed. 2. VACUUM has to compete with other processing for I/O. Neither of those factors can be alleviated by vacuuming more often. Jan has seen this phenomenon; I have seen this phenomenon; I have no reason to think that Jason is not describing the very same phenomenon. pg_autovacuum is well and useful, and I hesitate to try to count how many systems I have installed it on. Probably a dozen. I have added about as many patches to it as has Matthew O'Connor; I have a fair idea of what it does. It is a godsend in test systems or low traffic environments, by virtue of cutting down on the need to manually do vacuums or to script up cron jobs. It's exactly what is needed to make PostgreSQL usable in the long term for hosting small web apps, or to make PostgreSQL work well as a host for desktop applications. I'd like to see GnuCash use PostgreSQL by default, instead of its custom XML data format, and pg_autovacuum would be part of what would make that mix work. But it isn't a magical solution to all ills, and the scenarios that Jan Wieck and Jason Drake have been describing represent the pathological cases where pg_autovacuum can cause performance problems of its own. -- output = reverse(ofni.smrytrebil @ enworbbc) http://dev6.int.libertyrms.com/ Christopher Browne (416) 646 3304 x124 (land) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] out of date bufmgr README
Neil Conway [EMAIL PROTECTED] writes: Could someone who's aware of the bufmgr changes made for 7.2's lazy VACUUM comment on how this should be updated? The only problem with it is that the future tense should be replaced by the present tense ;-). Done --- thanks for noting the problem. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Port Reports: UnixWare/Failure/Priviledge Test
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: nothing happens, because the revoke is implicitly assumed to mean revoke whatever privileges I granted, and Larry's superuser hasn't granted any. The public privileges on language SQL were granted by user postgres, and they remain in force. So the later CREATE FUNCTION that the test expects to fail, succeeds. Is this a bug, or is it correct-per-spec behavior? It's correct. After chewing on it further, I decided that the spec is unable to provide any useful guidance, because it hasn't got the concept of superuser. It is however clear that having superusers generate their own grants to someone else's object is not within the privilege model of the spec. I think the solution I applied this afternoon (pretend that superusers are the object owner for GRANT/REVOKE purposes) is a reasonable answer. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 7.4RC1 planned for Monday
On Thu, 2003-10-30 at 23:13, Bruce Momjian wrote: If we do a short cycle, will we have enough features to justify a release? We could try to get PITR and Win32 done by January 1 and see if that can happen. It's worth noting that we've thought about doing quick major releases in the past, without much success: originally, 7.4 was going to be Win32 + PITR, released in a few months, and look how that turned out :-) Since the cost of migrating to a new major release is more-or-less constant (you need a complete initdb+reload whether the release took 3 weeks or 3 years), I'm still not in favour of a short release cycle. But in any case, the whole debate is somewhat academic unless someone does the work to get PITR and Win32 done very quickly. -Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Vacuum thoughts
On Mon, 2003-10-27 at 15:31, Jan Wieck wrote: Well, partial solution isn't quite what I would call it, and it surely needs integration with sequential scans. I really do expect the whole hack to fall apart if some concurrent seqscans are going on I'd rather see us implement a buffer replacement policy that considers both frequency + recency (unlike LRU, which considers only recency). Ideally, that would work automagically. I'm hoping to get a chance to implement ARC[1] during the 7.5 cycle. -Neil [1]: http://citeseer.nj.nec.com/megiddo03arc.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5
I thought someone might be interested in a data point I have comparing 7.3.4 and 7.4beta5 with results from our DBT-2 workload. Keep in mind I haven't done much tuning with either version. The following links have references iostat, vmstat, sar, readprofile (linux kernel profile), and oprofile (postgresql profile) statistics. Results from 7.3.4: http://developer.osdl.org/markw/dbt2-pgsql/184/ - metric 1354.58 Results from 7.4beta5 http://developer.osdl.org/markw/dbt2-pgsql/188/ - metric 1446.01 7.4beta5 offers more throughput. One significant difference I see is in the oprofile for the database. For the additional 7% increase in the metric, there are about 32% less ticks in SearchCatCache. These are the only database parameters I've explicitly set for each one, any other differences will be differences in default values: - shared_buffers = 4 - tcpip_socket = true - checkpoint_segments = 200 - checkpoint_timeout = 1800 - stats_start_collector = true - stats_command_string = true - stats_block_level = true - stats_row_level = true - stats_reset_on_server_start = true If anyone has any tuning recommendations for either 7.3 or 7.4, I'll be happy to try them. Or if anyone wants to be able to poke around on the system, we can arrange that too. Feel free to ask any questions. -- Mark Wong - - [EMAIL PROTECTED] Open Source Development Lab Inc - A non-profit corporation 12725 SW Millikan Way - Suite 400 - Beaverton, OR 97005 (503) 626-2455 x 32 (office) (503) 626-2436 (fax) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.4RC1 planned for Monday
- Original Message - From: Neil Conway [EMAIL PROTECTED] To: Bruce Momjian [EMAIL PROTECTED] Cc: Tatsuo Ishii [EMAIL PROTECTED]; Tom Lane [EMAIL PROTECTED]; Joshua Drake [EMAIL PROTECTED]; PostgreSQL Hackers [EMAIL PROTECTED] Sent: Friday, October 31, 2003 6:27 PM Subject: Re: [HACKERS] 7.4RC1 planned for Monday On Thu, 2003-10-30 at 23:13, Bruce Momjian wrote: If we do a short cycle, will we have enough features to justify a release? We could try to get PITR and Win32 done by January 1 and see if that can happen. It's worth noting that we've thought about doing quick major releases in the past, without much success: originally, 7.4 was going to be Win32 + PITR, released in a few months, and look how that turned out :-) Since the cost of migrating to a new major release is more-or-less constant (you need a complete initdb+reload whether the release took 3 weeks or 3 years), I'm still not in favour of a short release cycle. But in any case, the whole debate is somewhat academic unless someone does the work to get PITR and Win32 done very quickly. You don't have to upgrade to every new release. Maybe win32 needs to be done against the 7.4 codebase whenever that is branched, and could be released out of cycle. PITR doesn't seem to be going anywhere very fast from the messages I've seen here. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5
Excellent. I just noticed that most of the numbers in the system are given the numeric data type. Is there any particular reason you don't use integer (test enforced?)? On Fri, 2003-10-31 at 19:18, [EMAIL PROTECTED] wrote: I thought someone might be interested in a data point I have comparing 7.3.4 and 7.4beta5 with results from our DBT-2 workload. Keep in mind I haven't done much tuning with either version. The following links have references iostat, vmstat, sar, readprofile (linux kernel profile), and oprofile (postgresql profile) statistics. Results from 7.3.4: http://developer.osdl.org/markw/dbt2-pgsql/184/ - metric 1354.58 Results from 7.4beta5 http://developer.osdl.org/markw/dbt2-pgsql/188/ - metric 1446.01 7.4beta5 offers more throughput. One significant difference I see is in the oprofile for the database. For the additional 7% increase in the metric, there are about 32% less ticks in SearchCatCache. These are the only database parameters I've explicitly set for each one, any other differences will be differences in default values: - shared_buffers = 4 - tcpip_socket = true - checkpoint_segments = 200 - checkpoint_timeout = 1800 - stats_start_collector = true - stats_command_string = true - stats_block_level = true - stats_row_level = true - stats_reset_on_server_start = true If anyone has any tuning recommendations for either 7.3 or 7.4, I'll be happy to try them. Or if anyone wants to be able to poke around on the system, we can arrange that too. Feel free to ask any questions. signature.asc Description: This is a digitally signed message part
[HACKERS] Problems with whitespace-ignoring diff options
On OpenBSD 3.4, the diff options -b and -w have the interesting feature (actually listed as a bug) that they ignore whitespace for preparing the diff, but the exit status will be 1 nonetheless, if the files are at all different. This leads to several failures in the current regression tests, because the expected files are off by some whitespace. It appears we must not use the options for determining whether the test failed, only for creating the diff output. Or does anyone have a better idea? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for port reports
Bruce Momjian writes: It is time for people to report their port testing. Please test against current CVS or beta5 and report your 'uname -a'. This one is OK: OpenBSD ob.credativ.de 3.4 GENERIC#65 sparc -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Problems with whitespace-ignoring diff options
Peter Eisentraut [EMAIL PROTECTED] writes: It appears we must not use the options for determining whether the test failed, only for creating the diff output. Or does anyone have a better idea? AFAIK, there is no reason to ignore whitespace in determining whether a test succeeded. However, if a test fails, it is quite likely that a whitespace-sensitive diff will produce many lines of uninteresting diff, because of psql's habit of justifying column output --- any difference in the data value length where the actual difference occurs would impact all the rest of the query output, even though it's really the same. So if you can implement the above behavior easily, go for it. Keep in mind though that a reported failure accompanied by *no* visible diff would be highly annoying ;-). Can we arrange to produce a whitespace-sensitive diff output if the whitespace-insensitive kind shows nothing? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Vacuum thoughts
Neil Conway wrote: On Mon, 2003-10-27 at 15:31, Jan Wieck wrote: Well, partial solution isn't quite what I would call it, and it surely needs integration with sequential scans. I really do expect the whole hack to fall apart if some concurrent seqscans are going on I'd rather see us implement a buffer replacement policy that considers both frequency + recency (unlike LRU, which considers only recency). Ideally, that would work automagically. I'm hoping to get a chance to implement ARC[1] during the 7.5 cycle. Someone just started working on it this week. He emailed Jan and I. He hopes to have a patch in a few days. I will make sure he posts to hackers/patches. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5
[EMAIL PROTECTED] writes: 7.4beta5 offers more throughput. One significant difference I see is in the oprofile for the database. For the additional 7% increase in the metric, there are about 32% less ticks in SearchCatCache. Hmm. I have been profiling PG for some years now, and I cannot remember ever seeing a profile in which SearchCatCache topped everything else (the usual suspects for me are palloc/pfree support code). Can you give any explanation why it looks like that? Can your profiling code tell where the hotspot call sites of SearchCatCache are? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
