[HACKERS] Question regarding pfree and thread safety.
Is it safe to call pfree() from multiple threads? My Java backend will need to utilize finalizers. Objects like a saved execution plan that has been forgotten must be released when the wrapping Java object is finalized to avoid memory leaks. The finalizer is called from the garbage collector which in turn might run in a separate thread. I have two choices: 1. Let finalizers put pfree() candiates on a death row and let each call from SQL into my call manager pfree() the candidates found there. All death row management is of course subject to a mutex. 2. Let the finalizer call pfree directly and trust that it is thread safe. Advice is greatly appreciated. - thomas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Postgres v.7.3.4 - Performance tuning
On Thursday 15 January 2004 21:48, Michael Brusser wrote: I need to provide recommendations for optimal value for the shared_buffers. Any hints, or pointers to related reading would be very appreciated. Mike. First, read the annotated config file and performance guide here: http://www.varlena.com/varlena/GeneralBits/Tidbits/index.php If you think there's more to be done, subscribe to the performance list http://www.postgresql.org/lists.html -- Richard Huxton Archonet Ltd ---(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
[HACKERS] nomenclature
Just overheard one of my colleagues on the phone to one of our users taking them through the process of moving their PGDATA to a partition with space... With the various paths, service names, config files and environment variables PostgreSQL appears to have a multiple-personality disorder... Is it: postgresql (/etc/init.d/postgresql, postgresql.conf), or postmaster (main postmaster process), or postgres (postgres user), or pgsql (/var/lib/pgsql), or psql (psql SQL terminal), or pg (PG* environment variables, pg_* files)? I guess the point of this email is to point out the current proliferation of terms is not user friendly. Any plans/interest in standardisation? Thanks, Lee. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] nomenclature
Hi Lee On Jan 16, 2004, at 8:09 PM, Lee Kindness wrote: With the various paths, service names, config files and environment variables PostgreSQL appears to have a multiple-personality disorder... Is it: postgresql (/etc/init.d/postgresql, postgresql.conf), or postmaster (main postmaster process), or postgres (postgres user), or pgsql (/var/lib/pgsql), or psql (psql SQL terminal), or pg (PG* environment variables, pg_* files)? I guess the point of this email is to point out the current proliferation of terms is not user friendly. Any plans/interest in standardisation? Don't forget pl/pgsql! :) In my way of thinking, different things should have different names, which is what is going on here. Two of these are more or less user-customizable: the user who owns the database cluster, and the directory where the cluster and files are usually stored. However, the others are distinct, as you've clearly pointed out. They have different names because they are different. I too was a little confused when starting out with PostgreSQL as to what the difference was between some of these things, but they need different names so people can distinguish between them. However, this is compounded by the fact that I see (and have probably used) PostgreSQL, postgres, or pgsql all to refer to the whole thing in general. Then you've got people coming up with their own, such as Postgress, and Postgrees, two of which I've seen bandied about recently. But again, there needs to be names to refer to these different things. Michael Glaesemann grzm myrealbox com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] set search_path and pg_dumpall
Thanks for the input Tom. INMHO, this kind of statement should'nt cause any error even if the schema doesn't exit *yet*; because: 1) if the script comes for pg_dump[all], we KNOW that this statement is right 2) if it's typed in psql, and the user names the wrong schema, he will find out very quickly (benn there, done that)... You didn't reply to the second part of my mail witch prevents me to go to 7.4.1 Regards On Thu, 15 Jan 2004, Tom Lane wrote: Date: Thu, 15 Jan 2004 19:16:47 -0500 From: Tom Lane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: pgsql-hackers list [EMAIL PROTECTED], Peter Eisentraut [EMAIL PROTECTED] Subject: Re: [HACKERS] set search_path and pg_dumpall [EMAIL PROTECTED] writes: When a serch_path has been set, pg_dumpall correctly output a alter database xxx set search_path to 'xxx' but *BEFORE* the schema is created so it doesn't work. Hm. It's worse than that really: in ALTER DATABASE SET, we are trying to check the search path in the wrong context. Consider: regression=# create database foo; CREATE DATABASE regression=# alter database foo set search_path to 'fooschema'; ERROR: schema fooschema does not exist If we are not connected to database foo then we have no way to tell whether the requested search path is valid. Presently the backend is checking the path against the schemas in the *current* database, which is obviously bogus. A closely related case is this (which also represents a scenario where pg_dumpall will fail at the moment): regression=# create user foo; CREATE USER regression=# alter user foo set search_path to 'fooschema'; ERROR: schema fooschema does not exist I am inclined to think that raising an error here isn't a good idea either, since it's quite possible that the user's search path isn't meant to be used in the current database. We don't even have any way to tell which database it is meant to be used in. So I'm leaning to the thought that we shouldn't change pg_dumpall's behavior, but instead should relax the backend's error checking so that it doesn't reject these cases. To be specific, I think that for ALTER DATABASE/USER SET search_path, we only want to do a syntactic check that the search path is valid (ie, it's a list of identifiers), and not insist that it refer to existing schemas. The only case where checking schema existence is arguably useful is ALTERing the current database --- but if we do that, then we still have to do something to change pg_dumpall's behavior, and existing pg_dumpall scripts are still broken. So I'm content to say that we won't check regardless of which database is the target. Next question is how exactly to make the change. It seems like a really clean solution would involve adding another GucSource or GucContext value to denote that we're trying to validate an ALTER ... SET value, and changing the API for GUC variable assign hooks so that assign_search_path could find out that that's what we're doing. Should we go to that much trouble, and if so what should the modified API be? At the moment search_path seems to be the only GUC variable that has a context-sensitive checking routine, so maybe a quick kluge for just this variable is sufficient. I have a feeling the problem may come up in the future with other variables, though. Comments? regards, tom lane -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] nomenclature
I too was a little confused when starting out with PostgreSQL as to what the difference was between some of these things, but they need different names so people can distinguish between them. You make a good point, and I think that's easier for developers to work with. However, why do no other OSS projects use different names like that? Postmaster is particularly confusing for those new to PostgreSQL, since it's not clear that it belongs to PostgreSQL, and, indeed, seems more like a clever name for an MTA. If you look at apache, and mysql, they seem to be consistant (Red Hat apparently renames apache to httpd, however that is just generalizing the name, not making a new one). Simpler daemons tend to be consistant (like ftp, etc), but those don't really count because there aren't very many parts. MTAs usually have their own name, but sometimes steal the sendmail name. Bind calls itself named (another general name). Samba has sbmd. I can't point to any OSS project that completely renames its parts. I think a shortened version of the name makes sense (in this case postgres works well, but so does pgsql), and other projects do similar things. Psql for the client and postmaster for the daemon are the ones that really confuse people, I think. Now, is it worth changing? I doubt it. It doesn't take long to figure out, and would certainly cause confusion on the mailing lists. And, as you pointed out, it helps developers distinguish the parts, and maybe adds a little character to the software. Unless there's some kind of advocacy issue (i.e. people are avoiding the database because of perception), I can't think of much reason. Regards, Jeff Davis ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] nomenclature
On Jan 16, 2004, at 9:39 PM, Jeff Davis wrote: I can't point to any OSS project that completely renames its parts. I think a shortened version of the name makes sense (in this case postgres works well, but so does pgsql), and other projects do similar things. Psql for the client and postmaster for the daemon are the ones that really confuse people, I think. I'd agree with you there. I think they may be confusing for two different reasons: postmaster because there's no obvious connection (besides POSTmaster and POSTgreSQL), and psql because it's so close to pgsql and pl/pgsql. People may not realize psql is just one client (of other possible clients). They think it's tied much more closely to PostgreSQL than it actually is. (Well, it is packaged with the whole shebang and it can do a lot.) This may be one of the reasons for the discussions regarding the psql slash commands (e.g., \d). They may think it's just an SQL interface to the database, when it's more than that. In a way it's like saying phppgadmin shouldn't have buttons because it's not SQL-like enough :) But I digress. Now, is it worth changing? I doubt it. It doesn't take long to figure out, and would certainly cause confusion on the mailing lists. And, as you pointed out, it helps developers distinguish the parts, and maybe adds a little character to the software. Unless there's some kind of advocacy issue (i.e. people are avoiding the database because of perception), I can't think of much reason. I agree. Michael Glaesemann grzm myrealbox com ---(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] set search_path and pg_dumpall
I can't be the only one forsee frustration from users who typo the set
search_path statement and then can't figure out why their tables aren't
showing up... can we emit a warning that not all of the schemas in the
search path were found?
Robert Treat
On Fri, 2004-01-16 at 06:47, [EMAIL PROTECTED] wrote:
Thanks for the input Tom.
INMHO, this kind of statement should'nt cause any error even if the schema
doesn't exit *yet*; because:
1) if the script comes for pg_dump[all], we KNOW that this statement is
right
2) if it's typed in psql, and the user names the wrong schema, he will
find out very quickly (benn there, done that)...
You didn't reply to the second part of my mail witch prevents me to go to
7.4.1
Regards
On Thu, 15 Jan 2004, Tom Lane wrote:
Date: Thu, 15 Jan 2004 19:16:47 -0500
From: Tom Lane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list [EMAIL PROTECTED],
Peter Eisentraut [EMAIL PROTECTED]
Subject: Re: [HACKERS] set search_path and pg_dumpall
[EMAIL PROTECTED] writes:
When a serch_path has been set, pg_dumpall correctly output a alter
database xxx set search_path to 'xxx' but *BEFORE* the schema is created
so it doesn't work.
Hm. It's worse than that really: in ALTER DATABASE SET, we are trying
to check the search path in the wrong context. Consider:
regression=# create database foo;
CREATE DATABASE
regression=# alter database foo set search_path to 'fooschema';
ERROR: schema fooschema does not exist
If we are not connected to database foo then we have no way to tell
whether the requested search path is valid. Presently the backend
is checking the path against the schemas in the *current* database,
which is obviously bogus.
A closely related case is this (which also represents a scenario
where pg_dumpall will fail at the moment):
regression=# create user foo;
CREATE USER
regression=# alter user foo set search_path to 'fooschema';
ERROR: schema fooschema does not exist
I am inclined to think that raising an error here isn't a good idea
either, since it's quite possible that the user's search path isn't
meant to be used in the current database. We don't even have
any way to tell which database it is meant to be used in.
So I'm leaning to the thought that we shouldn't change pg_dumpall's
behavior, but instead should relax the backend's error checking so
that it doesn't reject these cases. To be specific, I think that
for ALTER DATABASE/USER SET search_path, we only want to do a
syntactic check that the search path is valid (ie, it's a list of
identifiers), and not insist that it refer to existing schemas.
The only case where checking schema existence is arguably useful is
ALTERing the current database --- but if we do that, then we still
have to do something to change pg_dumpall's behavior, and existing
pg_dumpall scripts are still broken. So I'm content to say that we
won't check regardless of which database is the target.
Next question is how exactly to make the change. It seems like a really
clean solution would involve adding another GucSource or GucContext
value to denote that we're trying to validate an ALTER ... SET value,
and changing the API for GUC variable assign hooks so that
assign_search_path could find out that that's what we're doing. Should
we go to that much trouble, and if so what should the modified API be?
At the moment search_path seems to be the only GUC variable that has a
context-sensitive checking routine, so maybe a quick kluge for just this
variable is sufficient. I have a feeling the problem may come up in the
future with other variables, though.
Comments?
regards, tom lane
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: [EMAIL PROTECTED]
--
Make your life a dream, make your dream a reality. (St Exupery)
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] [GENERAL] Bug and/or feature? Complex data types in tables...
Joe Conway [EMAIL PROTECTED] writes: Tom Lane wrote: ... That means that the contained fields had better not be out-of-line TOAST value references, because there's no way to keep track of them and keep from deleting the referenced value too soon. Why wouldn't we handle this just like we do when we build an array from elemental datums (i.e. allocate sufficient space and copy the individual datums into the structure)? Well, the problem is that there are tuples and there are tuples. We do *not* want to force expansion of TOAST references every time we build an intermediate tuple to return up one level in a plan. That would cost gobs of memory, and it's possible the expanded value will never actually be used at all (eg, the row might fail a join qual further up the plan). Ideally the forced expansion should only occur if a composite-type tuple is actually about to be stored on disk. Maybe this says that the toaster routines are the right place to take care of it after all, but I'm not quite sure where it should go. BTW, you could argue that TOAST references in a constructed array ought not be expanded until/unless the array gets written to disk, too. But the expense of scanning a large array on the off chance there's some TOAST references in there might dissuade us from doing that. (Hmm ... maybe use a flag bit in the array flag word?) The other point was that what's actually returned at the moment from a function-returning-tuple is a Datum that contains a pointer to a TupleTableSlot, not a pointer to a datum of this kind. If you had something akin to arrayin/arrayout, would this still need to be changed? I don't see the connection. This is an internal representation either way, and there's no point at which one would want to invoke an I/O routine. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Missed bet in toaster routines
Wouldn't it be a win for heap_tuple_toast_attrs() to fall out quickly if the tuple contains no varlena attributes? I'm thinking of adding a test like /* Nothing to do if tuple contains no varlena fields */ if ((newtup !HeapTupleAllFixed(newtup)) || (oldtup !HeapTupleAllFixed(oldtup))) /* do existing processing */ This is a pretty cheap test (just checking a header flag) and saves lots of useless scanning when it succeeds. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] nomenclature
On Fri, 16 Jan 2004, Jeff Davis wrote: I can't point to any OSS project that completely renames its parts. I think a shortened version of the name makes sense (in this case postgres works well, but so does pgsql), and other projects do similar things. Psql for the client and postmaster for the daemon are the ones that really confuse people, I think. I don't know, doesn't one of the databases out there use 'monitor' as their equivalent to psql? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] nomenclature
On Fri, 16 Jan 2004, Michael Glaesemann wrote: On Jan 16, 2004, at 9:39 PM, Jeff Davis wrote: I can't point to any OSS project that completely renames its parts. I think a shortened version of the name makes sense (in this case postgres works well, but so does pgsql), and other projects do similar things. Psql for the client and postmaster for the daemon are the ones that really confuse people, I think. I'd agree with you there. I think they may be confusing for two different reasons: postmaster because there's no obvious connection (besides POSTmaster and POSTgreSQL) This one I have to agree with also ... 'postmaster' always makes me think of the mail system ... *but* ... for those that are dealing with the database server, and who many never have seen a mail system in their life, the same may not be true ... The funny thing is that the postmaster doesn't really do anything, its the postgres process that does all the work ... if you think about it, the postmaster is actually aptly named, since it is the process that sorts out the incoming connections and assigns them to backend processes ... just like the postmaster does with your mail ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Question regarding pfree and thread safety.
Thomas Hallgren [EMAIL PROTECTED] writes: Is it safe to call pfree() from multiple threads? There are no multiple threads in the backend, and no provision whatever for thread safety. On anything, not only pfree. If your Java runtime cannot be coerced into a single-thread mode of operation, you would be well advised to keep it at arm's length in a separate process. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Missed bet in toaster routines
Tom Lane wrote: Wouldn't it be a win for heap_tuple_toast_attrs() to fall out quickly if the tuple contains no varlena attributes? I'm thinking of adding a test like /* Nothing to do if tuple contains no varlena fields */ if ((newtup !HeapTupleAllFixed(newtup)) || (oldtup !HeapTupleAllFixed(oldtup))) /* do existing processing */ This is a pretty cheap test (just checking a header flag) and saves lots of useless scanning when it succeeds. Why sure it would. That code is quite frequently called. 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])
[HACKERS] And ppl complain about *our* beta cycles ...
From the Firebird FAQ: The first beta was released on January 29, 2003. We are hoping to be close to a full release some time around Easter 2003. They are at RC8 right now ... running a *wee* bit behind scheduale :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] nomenclature
Marc G. Fournier wrote: On Fri, 16 Jan 2004, Michael Glaesemann wrote: On Jan 16, 2004, at 9:39 PM, Jeff Davis wrote: I can't point to any OSS project that completely renames its parts. I think a shortened version of the name makes sense (in this case postgres works well, but so does pgsql), and other projects do similar things. Psql for the client and postmaster for the daemon are the ones that really confuse people, I think. I'd agree with you there. I think they may be confusing for two different reasons: postmaster because there's no obvious connection (besides POSTmaster and POSTgreSQL) This one I have to agree with also ... 'postmaster' always makes me think of the mail system ... *but* ... for those that are dealing with the database server, and who many never have seen a mail system in their life, the same may not be true ... In all honesty, when I first installed Linux system with Postgresql I couldn't help but wonder why I had two different MTA's. The funny thing is that the postmaster doesn't really do anything, its the postgres process that does all the work ... if you think about it, the postmaster is actually aptly named, since it is the process that sorts out the incoming connections and assigns them to backend processes ... just like the postmaster does with your mail ... Perhaps postgresd, postgresqld, or pg_daemon might be a little more intuitive? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] nomenclature
On Fri, 16 Jan 2004, Thomas Swan wrote: Perhaps postgresd, postgresqld, or pg_daemon might be a little more intuitive? I think at this late stage in the game (almost 10 years), changing could be a bit difficult and confusing, no? :) I'd go with something like pgsqld myself though, keeps it short ... or we could go even shorter with just pgd ... But, I'm not, in any stretch of the imagination, advocating for change on this ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] nomenclature
Marc G. Fournier writes: I think at this late stage in the game (almost 10 years), changing could be a bit difficult and confusing, no? :) I'd go with something like pgsqld myself though, keeps it short ... or we could go even shorter with just pgd ... But, I'm not, in any stretch of the imagination, advocating for change on this ... If it's ever going to happen then the likely place would be in a Linux distribution or a re-package of PostgreSQL. I'm sure no one would be suprised if Red Hat had a new release with dbd, ~db, sql (or keeping PostgreSQL in it pgsqld, ~pgsql, pgsql)... Indeed a lot of the current inconsistencies are packaging issues... L. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] nomenclature
Marc G. Fournier wrote: On Fri, 16 Jan 2004, Thomas Swan wrote: Perhaps postgresd, postgresqld, or pg_daemon might be a little more intuitive? I think at this late stage in the game (almost 10 years), changing could be a bit difficult and confusing, no? :) I'd go with something like pgsqld myself though, keeps it short ... or we could go even shorter with just pgd ... But, I'm not, in any stretch of the imagination, advocating for change on this ... Agreed, to change it would be a bit insane. Although a little insanity often surrounds a major version release... I just thought the anecdote of confusing it for an MTA was a little funny. Thomas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] cache control?
Is there a way to force database to load a frequently-accessed table into cache and keep it there? Thanks, Mike. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Question regarding pfree and thread safety.
Ok, That was what I suspected, but I was not 100% sure that it applied to the memory allocation routines. It has not escaped me that most things in the backend are indeed intended for single-threading. I'm unaware of any way of coercing the Java runtime into single threading. Instead, I took advantage of the fact that there's a very clear border between Java and C and added a thread-fence to each an every crossing that safely prevents other threads from entering the backend functions. My intention is that writing functions and triggers in Java should be far less error-prone than writing them in C. And I understand and appreciate your concern, threading bugs are not fun to deal with. Using a separate process is a choice I abandoned from start. I wrote a rationale for this choice that you can find here: http://gborg.postgresql.org/project/pljava/genpage.php?jni_rationale. I would appreciate any comments on it very much. Regards, - thomas Tom Lane [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Thomas Hallgren [EMAIL PROTECTED] writes: Is it safe to call pfree() from multiple threads? There are no multiple threads in the backend, and no provision whatever for thread safety. On anything, not only pfree. If your Java runtime cannot be coerced into a single-thread mode of operation, you would be well advised to keep it at arm's length in a separate process. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] nomenclature
Thomas Swan wrote: I just thought the anecdote of confusing it for an MTA was a little funny. Funny yes, but unfortunatly all too common for newbies I think. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] cache control?
Michael Brusser [EMAIL PROTECTED] writes: Is there a way to force database to load a frequently-accessed table into cache and keep it there? No. BTW, this idea has been suggested in the past, so check the archives for the prior discussions on this topic. The usual response is that the PostgreSQL bufmgr should already placing hot pages into the cache, so there isn't really a need for this mechanism. (And if the bufmgr doesn't do this well enough, we should improve the bufmgr -- as Jan has done for 7.5) -Neil ---(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] nomenclature
Marc G. Fournier [EMAIL PROTECTED] writes: if you think about it, the postmaster is actually aptly named, since it is the process that sorts out the incoming connections and assigns them to backend processes ... just like the postmaster does with your mail ... Right, hence the witty pun :-) IMHO this whole debate is largely academic: it really wouldn't be practical to start renaming components at this point, whether they are perfectly named or not. -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] cache control?
On Fri, 16 Jan 2004, Michael Brusser wrote: Is there a way to force database to load a frequently-accessed table into cache and keep it there? Nope. But there is a new cache buffer handler that may make it into 7.5 that would make that happen automagically. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Missed bet in toaster routines
Jan Wieck [EMAIL PROTECTED] writes: Tom Lane wrote: Wouldn't it be a win for heap_tuple_toast_attrs() to fall out quickly if the tuple contains no varlena attributes? Why sure it would. That code is quite frequently called. I take it back --- the short-circuit test already exists, but it's at the call sites rather than in tuptoaster.c. However, it looks like we can tighten the tests a bit. For instance heap_delete invokes the toaster if HeapTupleHasExtended, whereas it seems to me it'd be sufficient to check HasExternal --- we don't care about deleting compressed-in-line stuff, do we? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] FYI , Intel CC and PostgreSQL , benchmark by pgsql
It would be interesting to see the results if you do this test again with : - scaling factor somewhere in the 100-300 range (so the generated db ~= your ram amount) - number of clients somewhere in 10-100 - number of transactions somewhere in 1000-1000 best wishes Mark P.s - Are you using the GENERIC kernel or have you built you own (e.g with SMP suppport for your hyperthreaded cpu?) jihuang wrote: Hi, I have a new server and some time to do an interesting simple benchmark. Compile PostgreSQL 7.4.1R by gcc3.2 and Intel CC 8.0 , and use pgbench to evaluate any difference.. Here is the result. -- CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3052.79-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX ,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 3221200896 (3071 MB) avail memory = 3130855424 (2985 MB) FreeBSD 5.1-RELEASE-p11 /usr/local/intel_cc_80/bin/icc -V Intel(R) C++ Compiler for 32-bit applications, Version 8.0 Build 20031211Z Package ID: l_cc_p_8.0.055_pe057 Copyright (C) 1985-2003 Intel Corporation. All rights reserved. FOR NON-COMMERCIAL USE ONLY gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.2 [FreeBSD] 20030205 (release) Application: PostgreSQL 7.4.1 Benchmark: pgbench Result : 1. IntelCC ( use ports/database/postgresql7 , default ) ./pgbench -U pgsql -c 30 test starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 1 number of clients: 30 number of transactions per client: 10 number of transactions actually processed: 300/300 tps = 34.975026 (including connections establishing) tps = 35.550815 (excluding connections establishing) 2. GNU cc( use ports/database/postgresql7 , default ) ./pgbench -U pgsql -c 30 test starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 1 number of clients: 30 number of transactions per client: 10 number of transactions actually processed: 300/300 tps = 38.968321 (including connections establishing) tps = 39.707451 (excluding connections establishing) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Reverse scans?
Would it be doable, and would it be useful, to try to alternate the directions of table and index scans every time each table/index was fully scanned? I was thinking that it could help cache performance at various levels in cases where data at the end of a large table, say, that remained in memory after a scan, would otherwise be flushed out by a new scan of the same table. If the next scan of the same table was to go in the other direction, any remains of the last time around that were still in the filesystem cache, buffer pool, hard disk cache etc. would stand a greater chance of being reused. Does that make sense at all? I tried searching the archives for some of the mailing lists but couldn't find anything related. Jeroen ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Replication question
When replication is implemented, what is going to happen with database
systems that rely heavily on sequences for primary keys?
For example, consider this simple table:
CREATE SEQUENCE IntervalType_IntervalTypeID_seq start 1 increment 1
maxvalue 2147483647 minvalue 1 cache 1 ;
CREATE TABLE IntervalType (
IntervalTypeID integer DEFAULT
nextval('IntervalType_IntervalTypeID_seq'::text) NOT NULL,
IntervalTypeDescription character varying(255),
MaximumValue integer,
FrequencyUnits double precision,
Constraint PK_IntervalType Primary Key (IntervalTypeID)
);
Now, when we replicate this table to other systems, will the sequence
parameters also flow to the targets?
A more interesting question is what happens if we need to revert to a
prior version (where -- for instance -- the maximum value of the
sequence was smaller than it is right now). Will the target system have
the sequence value reduced?
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] And ppl complain about *our* beta cycles ...
Marc G. Fournier wrote: From the Firebird FAQ: The first beta was released on January 29, 2003. We are hoping to be close to a full release some time around Easter 2003. They are at RC8 right now ... running a *wee* bit behind scheduale :) Yes, they're pretty late. Last time I read, the only major issues preventing their final release is around the installer. The 1.5 codebase itself has been stabilized for quite a while. Practically all work is now done to the 2.0 branch/HEAD. They have several goodies in store for the 2.0 release (e.g.: incremental backup). I think the Firebird team wants to make sure that their first public release to the world is really good. (Okay, they have some 1.0.x releases too but these were mainly bugfixes for IB 6.0, its predecessor; and there are *lots* of bugs being fixed). FB 1.5 is the first version that uses the new C++ codebase. Anyway, I'm certainly not among those who complain. I believe Postgres is already moving ahead faster than any other open source and semi-commercial database projects that I know of. You guys are doing a great great job. :-) -- dave ---(end of broadcast)--- TIP 8: explain analyze is your friend
