Re: [HACKERS] How to Sponsor a Feature
Greg Smith wrote: On Wed, 11 Jun 2008, Andrew Dunstan wrote: If we want to help people to sponsor features, then I think we need to deal with subjects like finding someone to undertake the development, the sponsor's relationship with the developer, methods and times of payment, etc. The bit on the wiki is helpful for developers trying to get a new feature implemented but I think that's where its scope ends. There seem to be occasional person wandering by here that it really doesn't help though. Periodically you'll see I want feature $X in PostgreSQL. I'm willing to help fund it. What do I do?. In most of those that have wandered by recently, $X is a known feature any number of other people want. Good sample cases here are recent requests to help fund or implement materialized views, supporting queries on read-only slaves, and SQL window support. I don't think these people need guidance on how to manage the project, they need some sort of way to feel comfortable saying will pledge $Y for feature $X in a way that makes sense on both sides. That's what I thought, too. That page just needs a different title. Best Regards Michael Paesold -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] rawhide report: 20080612 changes
Hm. Someone had his second finger chainsawed? Where is 8.3.2? The ftp browser also shows 8.3.1 and 8.3.3, and 8.3.1 is the latest on the main page. Rawhide írta: postgresql-8.3.3-1.fc10 --- * Wed Jun 11 18:00:00 2008 Tom Lane [EMAIL PROTECTED] 8.3.3-1 - Update to PostgreSQL 8.3.3. - Remove postgresql-prefer-ncurses.patch, no longer needed in recent Fedora releases because libtermcap is gone. -- -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] rawhide report: 20080612 changes
8.3.2 was pulled back because of an urgent bugfix, and re-released as 8.3.3 since it had already hit the mirrors. 8.3.3 has not been officially releasde yet, but it will be out soon. //Magnus Zoltan Boszormenyi wrote: Hm. Someone had his second finger chainsawed? Where is 8.3.2? The ftp browser also shows 8.3.1 and 8.3.3, and 8.3.1 is the latest on the main page. Rawhide írta: postgresql-8.3.3-1.fc10 --- * Wed Jun 11 18:00:00 2008 Tom Lane [EMAIL PROTECTED] 8.3.3-1 - Update to PostgreSQL 8.3.3. - Remove postgresql-prefer-ncurses.patch, no longer needed in recent Fedora releases because libtermcap is gone. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] rawhide report: 20080612 changes
Thanks for the info. Magnus Hagander írta: 8.3.2 was pulled back because of an urgent bugfix, and re-released as 8.3.3 since it had already hit the mirrors. 8.3.3 has not been officially releasde yet, but it will be out soon. //Magnus Zoltan Boszormenyi wrote: Hm. Someone had his second finger chainsawed? Where is 8.3.2? The ftp browser also shows 8.3.1 and 8.3.3, and 8.3.1 is the latest on the main page. Rawhide írta: postgresql-8.3.3-1.fc10 --- * Wed Jun 11 18:00:00 2008 Tom Lane [EMAIL PROTECTED] 8.3.3-1 - Update to PostgreSQL 8.3.3. - Remove postgresql-prefer-ncurses.patch, no longer needed in recent Fedora releases because libtermcap is gone. -- -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] How to Sponsor a Feature
Greg Smith wrote: On Wed, 11 Jun 2008, Andrew Dunstan wrote: If we want to help people to sponsor features, then I think we need to deal with subjects like finding someone to undertake the development, the sponsor's relationship with the developer, methods and times of payment, etc. The bit on the wiki is helpful for developers trying to get a new feature implemented but I think that's where its scope ends. We discussed this in the PGCon dev's meeting, and the outcome of the discussion was that we needed to put up a wiki page explaining to those trying to pledge the money what to do and what to expect. David took the first step by writing the page being complained about. If the page doesn't explain what the title says, then the contents of the page needs to be fixed (not the title). -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] .psqlrc output for \pset commands
Tom Lane wrote: I think the reason for the current behavior is to allow \set QUIET in .psqlrc to affect the printing of the banner. Are we prepared to give that up? I'm using that behavior! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] Automating our version-stamping a bit better
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Am Monday, 9. June 2008 schrieb Tom Lane: So while tagging the upcoming releases, I got annoyed once again about what a tedious, error-prone bit of donkeywork it is. Could you explain what the problem is? Your script sounds like an ad hoc workaround for some problem, but I haven't seen the problem actually defined. The problem is having to manually insert the version number into half a dozen different files, in half a dozen different formats, while preparing an update release. (And multiply that by several back branches, with several slightly different sets of changes to make.) This is not only tedious but quite error-prone --- if you check the CVS logs for the affected files you'll note we have missed changes more than once. I don't think we've yet wrapped a mis-labeled tarball, but it's going to happen sooner or later if we keep doing this manually. I suspect you are wondering why we don't use the makefile infrastructure to fix the numbers instead. I think the reason is that most of the files in question are for Windows and we can't assume very much about the available tools for fixing them at build time. In any case, I'd be hesitant to back-patch such a fix. Doing it this way means that the script only has to work on our own machines, not in any weird build environment someone might have, so it seems a lot safer to drop into the back branches. Yes, I like the idea of automating this. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Overhauling GUCS
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Also, I'd actually assert that 10 seems to be perfectly adequate for the majority of users. That is, the number of users where I've recommended increasing d_s_t for the whole database is smaller than the number where I don't, and of course we never hear from most users at all. So I'm pretty happy recommending Leave the default. If you encounter problem queries, increase it to 100, and analyse the database. Really? I'm the opposite: I never leave a client's setting at 10, that's just asking for trouble. Making it 100 *after* you encounter problem queries is reactive; I prefer being proactive. Nor is a setting of 10 perfectly adequate: I think you might be the last person on the lists who thinks so. That train has left the station, we've been trying to decide what a better default should be other than 10, and, more to the point, how to quantitatively measure it. The problem is, you really can't. Sure, you can graph a tiny increase in ANALYZE time and disk space, but there are no stock queries we can use to measure an increase in planning time. Frankly, I'd be shocked if there is any significant difference and all compared to the actual query run time. The orders of magnitude speed up of certain queries when the d_s_t goes above 98 is what spawned my original thread proposing a change to 100: http://markmail.org/message/tun3a3juxlsyjbsw While it's easy to get bogged down in theory about what things d_s_t should measure, the optimal size of buckets, etc., it's still a severe performance regression bug that should be fixed, IMO. Changing the subject line as well: this is only tangentially related to overhauling GUCS, although I'll point out again that this particular config is a good example of one that needs more comments. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200806121213 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkhRTKYACgkQvJuQZxSWSsjGvACeJkXZJ8cP385W9UXKzLHdzhvw gqQAoJWdrepFbkxR2be7oetK8/o/yd9I =w469 -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Options for protocol level cursors
Is there anyway to bind a cursor with SCROLL and WITH HOLD at the protocol level? Or perhaps configuring it so after binding it? I know you can use DECLARE, but I believe that this inhibits the driver from being able to select the transfer format for individual columns; it's all binary or it's all text. Also, I don't think I can DECLARE against a prepared statement, save restating the query, no? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Overhauling GUCS
Greg Sabino Mullane [EMAIL PROTECTED] writes: The orders of magnitude speed up of certain queries when the d_s_t goes above 98 is what spawned my original thread proposing a change to 100: http://markmail.org/message/tun3a3juxlsyjbsw That was a pretty special case (LIKE/regex estimation), and we've since eliminated the threshold change in the LIKE/regex estimates anyway, so there's no longer any reason to pick 100 as opposed to any other number. So we're still back at what's a good value and why?. Frankly, I'd be shocked if there is any significant difference and all compared to the actual query run time. I'm still concerned about the fact that eqjoinsel() is O(N^2). Show me some measurements demonstrating that a deep nest of equijoins doesn't get noticeably more expensive to plan --- preferably on a datatype with an expensive equality operator, eg numeric --- and I'm on board. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Options for protocol level cursors
James William Pye [EMAIL PROTECTED] writes: Is there anyway to bind a cursor with SCROLL and WITH HOLD at the protocol level? No, and for at least the first of those I don't see the point, since the protocol doesn't offer any behavior other than forward fetch. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Options for protocol level cursors
On Jun 12, 2008, at 10:08 AM, Tom Lane wrote: James William Pye [EMAIL PROTECTED] writes: Is there anyway to bind a cursor with SCROLL and WITH HOLD at the protocol level? No, and for at least the first of those I don't see the point, since the protocol doesn't offer any behavior other than forward fetch. That protocol level inability doesn't keep you from using MOVE on cursor's name. And yes, it yield the appropriate errors when you try to MOVE backwards on a protocol declared cursor. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Overhauling GUCS
Greg Sabino Mullane [EMAIL PROTECTED] writes: Also, I'd actually assert that 10 seems to be perfectly adequate for the majority of users. That is, the number of users where I've recommended increasing d_s_t for the whole database is smaller than the number where I don't, and of course we never hear from most users at all. So I'm pretty happy recommending Leave the default. If you encounter problem queries, increase it to 100, and analyse the database. Really? I'm the opposite: I never leave a client's setting at 10, that's just asking for trouble. Making it 100 *after* you encounter problem queries is reactive; I prefer being proactive. Have you ever measured the system speed before and after? Nor is a setting of 10 perfectly adequate: What percentage of your plans actually change with the larger statistics? How many for the better? How many were massively improved? I suspect you're looking at some single-digit percentage slowdown for planning across the board. In exchange if you a) have simple queries you probably see none improving. If you b) have moderately complex queries you probably get some single-digit percentage of them with improvements. And if you c) have very complex queries you probably have a handful of them which see massive improvements. Across the internet there are a whole lot more applications of type (a) than the others... Frankly, I'd be shocked if there is any significant difference and all compared to the actual query run time. Well you might start preparing to be shocked. Note that retrieving the statistics is a query itself so it's not hard for it to be comparable to a similarly simple query. It's not hard for a simple query using multiple columns to be using more records of statistics than it is from the actual data. And things can look much worse if that data is TOASTed and requires further lookups and/or decompression... The orders of magnitude speed up of certain queries when the d_s_t goes above 98 is what spawned my original thread proposing a change to 100: http://markmail.org/message/tun3a3juxlsyjbsw While it's easy to get bogged down in theory about what things d_s_t should measure, the optimal size of buckets, etc., it's still a severe performance regression bug that should be fixed, IMO. It was, three months ago: http://archives.postgresql.org/pgsql-committers/2008-03/msg00129.php 100 is no longer a magic threshold for LIKE queries (in CVS HEAD) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Overhauling GUCS
Bruce, I am concerned that each wizzard is going to have to duplicate the same logic each time, and adjust to release-based changes. I think that's a feature, not a bug. Right now, I'm not at all convinced that my algorithms for setting the various major dials are great (I just think that nobody yet has better). So I think we should *encourage* people to write their own wizards until we find one that works reasonably well. -- Josh Berkus PostgreSQL @ Sun San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)
Heikki Linnakangas wrote: Zdenek Kotala wrote: 4) Implementation The main point of implementation is to have several version of PageHeader structure (e.g. PageHeader_04, PageHeader_03 ...) and correct structure will be handled in special branch (see examples). (this won't come as a surprise as we talked about this in PGCon, but) I think we should rather convert the page structure to new format in ReadBuffer the first time a page is read in. That would keep the changes a lot more isolated. Note that you need to handle not only page header changes, but changes to internal representations of different data types, and changes like varvarlen and combocid. Those are things that have happened in the past; in the future, I'm foreseeing changes to the toast header, for example, as there's been a lot of ideas related to toast options compression. I understand the goal of having good modularity (not having ReadBuffer modify the page), but I am worried that doing multi-version page processing in a modular way is going to spread version-specific information all over the backend code, making is harder to understand. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal - improve eqsel estimates by including histogram bucket numdistinct statistics
Assuming that the threshold for switching to an indexscan is somewhere around selectivity 0.005 (I am not certain offhand, but it's in that general area), this cannot possibly require more than 200 MCV slots, and for most data distributions it'd be a whole lot less. Thats a really good point. Given such an MCV list, the planner will always make the right choice of whether to do index or seqscan Given that, wouldn't it be smarter to consider a value as an mcv candidate iff it has a density greater than 0.005, rather than having a count greater than 1.5*average? This would allow people to raise the hard mcv limit without having to worry as much about including worthless mcv values... Cheers, Nathan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal - improve eqsel estimates by including histogram bucket numdistinct statistics
Nathan Boley [EMAIL PROTECTED] writes: Given that, wouldn't it be smarter to consider a value as an mcv candidate iff it has a density greater than 0.005, rather than having a count greater than 1.5*average? Yeah, perhaps ... want to experiment with that? Though I'd be a bit worried about how to get the threshold right, seeing that it will depend a whole lot on what the user has selected for random_page_cost and other parameters. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cannot use result of (insert..returning)
Andrew Dunstan wrote: I need to use query like: select (insert into test (a) values (x) returning b),c from anytable where condition but it say ERROR: syntax error at or near into Is this a bug? No, it's a known limitation. Is there a TODO item for this? I don't see one, do you? Allow INSERT/UPDATE ... RETURNING inside a SELECT 'FROM' clause http://archives.postgresql.org/pgsql-general/2006-09/msg00803.php http://archives.postgresql.org/pgsql-hackers/2006-10/msg00693.php Yes, but the TODO item talks about its use in the FROM clause, while the failed query is using it in the target list. Updated TODO with new URL is: * Allow INSERT/UPDATE ... RETURNING inside a SELECT 'FROM' clause or target list http://archives.postgresql.org/pgsql-general/2006-09/msg00803.php http://archives.postgresql.org/pgsql-hackers/2006-10/msg00693.php http://archives.postgresql.org/pgsql-hackers/2008-06/msg00124.php -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] .psqlrc output for \pset commands
On Wed, 2008-06-11 at 19:24 -0400, Bruce Momjian wrote: Is this desirable? \set QUIET at the top of .psqlrc fixes it, but I am wondering if we should be automatically doing quiet while .psqlrc is processed. There is some precedent for not emitting the messages: most Unix tools don't echo the results of applying their .rc files at startup. Personally, I run psql frequently but very rarely modify my .psqlrc, so seeing timing is on and similar messages echoed to the screen is almost always noise. -Neil -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] .psqlrc output for \pset commands
Neil Conway wrote: On Wed, 2008-06-11 at 19:24 -0400, Bruce Momjian wrote: Is this desirable? \set QUIET at the top of .psqlrc fixes it, but I am wondering if we should be automatically doing quiet while .psqlrc is processed. There is some precedent for not emitting the messages: most Unix tools don't echo the results of applying their .rc files at startup. Personally, I run psql frequently but very rarely modify my .psqlrc, so seeing timing is on and similar messages echoed to the screen is almost always noise. Yea, that was really my point --- our current behavior doesn't match the way most Unix tools behave when executing startup files. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Overhauling GUCS
Josh Berkus wrote: Bruce, I am concerned that each wizard is going to have to duplicate the same logic each time, and adjust to release-based changes. I think that's a feature, not a bug. Right now, I'm not at all convinced that my algorithms for setting the various major dials are great (I just think that nobody yet has better). So I think we should *encourage* people to write their own wizards until we find one that works reasonably well. I am thinking a web-based wizard would make the most sense. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Overhauling GUCS
Bruce, I am thinking a web-based wizard would make the most sense. I'd prefer command-line, so that people could run it on their own servers. For one thing, we need to generate at least two files on many platforms; a postgresql.conf and a sysctl. -- Josh Berkus PostgreSQL @ Sun San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Overhauling GUCS
Josh Berkus wrote: Bruce, I am thinking a web-based wizard would make the most sense. I'd prefer command-line, so that people could run it on their own servers. For one thing, we need to generate at least two files on many platforms; a postgresql.conf and a sysctl. They can just download the files the need from the web page, no? -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Overhauling GUCS
On Jun 12, 2008, at 11:21 AM, Bruce Momjian wrote: Josh Berkus wrote: Bruce, I am concerned that each wizard is going to have to duplicate the same logic each time, and adjust to release-based changes. I think that's a feature, not a bug. Right now, I'm not at all convinced that my algorithms for setting the various major dials are great (I just think that nobody yet has better). So I think we should *encourage* people to write their own wizards until we find one that works reasonably well. I am thinking a web-based wizard would make the most sense. There's a definite need for an interactive GUI wizard (bundle with the Windows and OS X installers, at least). And a commandline wizard would certainly be nice, both interactive and non-interactive. Mostly for including in install scripts on unix platforms. And a web-based wizard would be useful too. And all of them would benefit from being able to both modify an existing configuration file, and to generate one from scratch. It looks like it's going to be reasonably easy to abstract away the interface to the user such that the first two (and likely the third) can be built from the same codebase, meaning that the smarts about how to set the various GUC settings (based on RAM available, estimates of database size and usage) can be maintained in one place. Cheers, Steve -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses
Hi all, There is a TODO Item to allow pg_hba.conf to specify host names along with IP addresses. I'd like to work on this feature, if nobody is working too and no objection exists. Thanks. -- []s Dickson S. Guedes - Projeto Colmeia - Curitiba - PR +55 (41) 3254-7130 ramal: 27 http://makeall.wordpress.com/ http://pgcon.postgresql.org.br/ http://planeta.postgresql.org.br/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses
Dickson S. Guedes wrote: Hi all, There is a TODO Item to allow pg_hba.conf to specify host names along with IP addresses. I'd like to work on this feature, if nobody is working too and no objection exists. Please do --- I know of no one working on that. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Overhauling GUCS
On Thu, 12 Jun 2008, Bruce Momjian wrote: I am thinking a web-based wizard would make the most sense. I have not a single customer I work with who could use an external web-based wizard. Way too many companies have privacy policy restrictions that nobody dare cross by giving out any info about their server, or sometimes that they're even using PostgreSQL inside the firewall. If it's not a tool that you can run on the same server you're running PostgreSQL on, I'd consider that another diversion that's not worth pursuing. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] default client encoding in postgresql.conf
looking in my freshly installed 8.3.3, I see this in the postgresql.conf
#client_encoding = sql_ascii# actually, defaults to database
# encoding
Now, certainly initdb can't know for sure what encoding a future database will
be in, but since it does know what encoding template0 friends will be in,
and most databases are copied from those (including encoding), wouldn't a
better default be to set it the encoding of template0?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] How to Sponsor a Feature
On Jun 12, 2008, at 8:49 AM, Alvaro Herrera wrote: Greg Smith wrote: On Wed, 11 Jun 2008, Andrew Dunstan wrote: If we want to help people to sponsor features, then I think we need to deal with subjects like finding someone to undertake the development, the sponsor's relationship with the developer, methods and times of payment, etc. The bit on the wiki is helpful for developers trying to get a new feature implemented but I think that's where its scope ends. We discussed this in the PGCon dev's meeting, and the outcome of the discussion was that we needed to put up a wiki page explaining to those trying to pledge the money what to do and what to expect. David took the first step by writing the page being complained about. If the page doesn't explain what the title says, then the contents of the page needs to be fixed (not the title). So were there decisions in the dev meeting about how the community wants to handle people wanting to sponsor a project? Do they donate to SPI? Do we have an escrow fund? Do we just point them at one of the Postgres Companies and hope they're willing to pay for the whole thing? -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] default client encoding in postgresql.conf
Robert Treat [EMAIL PROTECTED] writes: looking in my freshly installed 8.3.3, I see this in the postgresql.conf #client_encoding = sql_ascii# actually, defaults to database # encoding Now, certainly initdb can't know for sure what encoding a future database will be in, but since it does know what encoding template0 friends will be in, and most databases are copied from those (including encoding), wouldn't a better default be to set it the encoding of template0? No. Setting it at all in postgresql.conf is generally the wrong thing; the right thing is to let the default behavior (ie, make it equal to the database encoding) happen. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)
On Jun 11, 2008, at 10:42 AM, Heikki Linnakangas wrote: Another issue is that it might not be possible to update a page for lack of space. Are we prepared to assume that there will never be a transformation we need to apply that makes the data bigger? We do need some solution to that. One idea is to run a pre-upgrade script in the old version that scans the database and moves tuples that would no longer fit on their pages in the new version. This could be run before the upgrade, while the old database is still running, so it would be acceptable for that to take some time. That means old versions have to have some knowledge of new versions. There's also a big race condition unless the old version starts taking size requirements into account every time a page is dirtied. No doubt people would prefer something better than that. Another idea would be to have some over-sized buffers that can be used as the target of conversion, until some tuples are moved off to another page. Perhaps the over-sized buffer wouldn't need to be in shared memory, if they're read-only until some tuples are moved. This is pretty hand-wavy, I know. The point is, I don't think these problems are insurmountable. -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)
Tom Lane wrote: Another issue is that it might not be possible to update a page for lack of space. Are we prepared to assume that there will never be a transformation we need to apply that makes the data bigger? In such a situation an in-place update might be impossible, and that certainly takes it outside the bounds of what ReadBuffer can be expected to manage. Would a possible solution to this be that you could 1. Upgrade to the newest minor-version of the old release (which has knowledge of the space requirements of the new one). 2. Run some new maintenance command like vacuum expand or vacuum prepare_for_upgrade or something that would split any too-full pages, leaving only pages with enough space. 3. Only then shutdown the old server and start the new major-version server. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] b64_encode and decode
I require base64 or some similar encoding scheme from a C language extension and need it to be as fast as reasonably possible. In src/backend/utils/adt/encode.c there are functions b64_encode and b64_decode which would be ideal but these are defined static and so are not available to my code. I know I could call these functions indirectly by calling binary_ecncode through DirectFunctionCalln() but this is a whole lot more complexity and overhead than I'd like. I note that /contrib/pgcrypto/pgp-armor.c appears to have its own copies of these 2 functions and now I have elected to do the same. So, would there be any chance of redefining the base64 functions in encode.c as extern to eliminate this redundancy? __ Marc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] How to Sponsor a Feature
Decibel! wrote: So were there decisions in the dev meeting about how the community wants to handle people wanting to sponsor a project? Do they donate to SPI? Do we have an escrow fund? Do we just point them at one of the Postgres Companies and hope they're willing to pay for the whole thing? No, there weren't decisions. Donating via SPI is hard because it is a non-profit, and I think someone argued that paying someone to do development could cause trouble on the IRS side of this. I think what this page needs to say is that we are a community-oriented project and thus the prospective sponsor needs to approach a company or individual developer, with an understanding in the fact that even if the patch turns out to work, it could be rejected by the community. This is what was said at the meeting, and I'm surprised that the page is instead talking about how we interact in pgsql-hackers. There was no solution proposed to the escrow problem, nor to allow sponsoring of one feature by multiple independent individuals. Incidentally, we have minutes from the meeting. Is it OK to publish them openly? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] How to Sponsor a Feature
Decibel! wrote: On Jun 12, 2008, at 8:49 AM, Alvaro Herrera wrote: Greg Smith wrote: On Wed, 11 Jun 2008, Andrew Dunstan wrote: If we want to help people to sponsor features, then I think we need to deal with subjects like finding someone to undertake the development, the sponsor's relationship with the developer, methods and times of payment, etc. The bit on the wiki is helpful for developers trying to get a new feature implemented but I think that's where its scope ends. We discussed this in the PGCon dev's meeting, and the outcome of the discussion was that we needed to put up a wiki page explaining to those trying to pledge the money what to do and what to expect. David took the first step by writing the page being complained about. If the page doesn't explain what the title says, then the contents of the page needs to be fixed (not the title). So were there decisions in the dev meeting about how the community wants to handle people wanting to sponsor a project? Do they donate to SPI? Do we have an escrow fund? Do we just point them at one of the Postgres Companies and hope they're willing to pay for the whole thing? Who said anything about there being decisions? The only decision made was to create this docvument, AFAIR. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Overhauling GUCS
On Jun 11, 2008, at 9:34 PM, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: The idea has a fundamental logical flaw, which is that it's not clear which parameter wins if the user changes both. Yes, you could get into problems by having variable dependency loops, Who said anything about loops? What I am talking about is what happens during set memory_usage = X; // implicitly sets work_mem = X/100, say set work_mem = Y; set memory_usage = Z; My initial thought was that this would behave like a shell script variable, meaning once you set something it would affect all references to it below in postgresql.conf. The problem with that is that we comment out all settings, so there isn't a logical order like you would have in a shell script. I was not thinking of memory_usage implicity changing anything. I figured postgresql.conf would have: memory_usage = 100 work_mem = $memory_usage * 0.75 If you change memory_usage via SET, it will not change work_mem at all because you are not re-initializing the variables. Why? That's the exact opposite of what I'd expect. If I want a setting's value to be $memory_usage * .75, that's what I want it to be. Not some value based on whatever $memory_usage was set to when work_mem happened to be changed. Of course, if you set something to a hard value with no variables, then that's what it's set to. I am kind of lost how this would work logically and am willing to think about it some more, but I do think we aren't going to simplify postgresql.conf without such a facility. Agreed. And I think it's a lot more elegant for dealing with day-to- day tuning than some kind of external wizzard. The big problem I see is that right now everything has a constant default. If we allowed memory_usage to change some of the defaults, how would we signal that we want the variables based on it to change their values? This is your behind-the-scenes problem you mentioned. I would suggest that we just re-evaluate everything whenever any setting is changed (this assumes that we store postgresql.conf internally in some fashion, so that we're not actually hitting the file all the time and possibly picking up random edits). -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] Options for protocol level cursors
James William Pye [EMAIL PROTECTED] writes: On Jun 12, 2008, at 10:08 AM, Tom Lane wrote: James William Pye [EMAIL PROTECTED] writes: Is there anyway to bind a cursor with SCROLL and WITH HOLD at the protocol level? No, and for at least the first of those I don't see the point, since the protocol doesn't offer any behavior other than forward fetch. That protocol level inability doesn't keep you from using MOVE on cursor's name. Sure, but if you're willing to use a SQL-level operation on the portal then you could perfectly well declare the cursor at SQL level too. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] b64_encode and decode
Marc Munro wrote: I require base64 or some similar encoding scheme from a C language extension and need it to be as fast as reasonably possible. In src/backend/utils/adt/encode.c there are functions b64_encode and b64_decode which would be ideal but these are defined static and so are not available to my code. I know I could call these functions indirectly by calling binary_ecncode through DirectFunctionCalln() but this is a whole lot more complexity and overhead than I'd like. I note that /contrib/pgcrypto/pgp-armor.c appears to have its own copies of these 2 functions and now I have elected to do the same. So, would there be any chance of redefining the base64 functions in encode.c as extern to eliminate this redundancy? Just how much complexity do you think calling binary_encode involves? You can probably do the whole thing in one or two lines of code. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] b64_encode and decode
Marc Munro [EMAIL PROTECTED] writes: So, would there be any chance of redefining the base64 functions in encode.c as extern to eliminate this redundancy? It'd only last until the next time Bruce runs his script that static-izes things that aren't used outside their own module ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Overhauling GUCS
Decibel! [EMAIL PROTECTED] writes: On Jun 11, 2008, at 9:34 PM, Bruce Momjian wrote: I am kind of lost how this would work logically and am willing to think about it some more, but I do think we aren't going to simplify postgresql.conf without such a facility. Agreed. And I think it's a lot more elegant for dealing with day-to- day tuning than some kind of external wizzard. You guys call this simplification? You're out of your minds. This proposal is ridiculously complicated, and yet it still fails even to consider adjusting non-numeric parameters. And what about things that require more than a trivial arithmetic expression to compute? It's not hard at all to imagine wanting log, sqrt, etc. We do not need to put computational capability into GUC. Any computations needed to determine a parameter setting should be done by a wizard. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] How to Sponsor a Feature
On Thu, 12 Jun 2008, Alvaro Herrera wrote: Incidentally, we have minutes from the meeting. Is it OK to publish them openly? There's a set of minutes already up at http://wiki.postgresql.org/wiki/PgCon_2008_Developer_Meeting There was no solution proposed to the escrow problem, nor to allow sponsoring of one feature by multiple independent individuals. Pity, as those are the main things I get asked about. I've been thinking about this a fair amount recently, and it is difficult to figure out how SPI can handle this in reasonable way. It almost has to keep a hands-off approach, but the centeral organizers here are where people would think they should come for advice in this area. The best approach I've thought of is to have something like http://www.postgresql.org/support/professional_support this is instead a catalog of companies and/or associated worker bees who have successfully had submissions commited. Then the only interaction SPI/Core would have is to confirm that the claims people were making about what patches they were involved in were factual, which should be easy enough to verify just with the release notes, while disclaiming any interaction in contracting with said companies/individuals. This implements a meritocracy suggesting who people might work with by noting what areas they've worked in successfully before. For example, the last time I fielded one of these, the person I was advising wanted some PITR work done. I of course pointed them toward 2ndquadrant because everything they asked about was in code Simon wrote in the first place, and some pointers over to the release notes were sufficient to prove that was true. As for a format, I was thinking the directory would be organized like this: Company Person A 8.3 features involved in 8.2 features Person B 8.2 features ... Current/future projects 8.4 add feature Eventually add feature Nothing new, really, I'm just suggesting an alternate view on the data that's available if you know how to look for it, structured in a way that would make it easier for potential sponsors to navigate. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] b64_encode and decode
On Thu, 2008-06-12 at 19:07 -0400, Andrew Dunstan wrote: Marc Munro wrote: I require base64 or some similar encoding scheme from a C language. . . I know I could call these functions indirectly by calling binary_ecncode through DirectFunctionCalln() but this is a whole lot more complexity and overhead than I'd like. . . Just how much complexity do you think calling binary_encode involves? You can probably do the whole thing in one or two lines of code. I'm sure that's true once I've got my head around the mechanism, but it adds two levels of indirection that seem quite unnecessary, and given that the author of pgcrypto has also wound up copying the functions I guess I'm not the only one who'd rather avoid it. If there are good reasons not to expose the functions, or if the hackers just don't want to do it I'm fine with that. For dealing with 8.3 and earlier I will have to live with the redundancy. For 8.4 I'd like not to, but it's really not a big deal. Thanks for the response though. Being able to get a response from developers means a lot. I used to be an Oracle DBA and I have to say the response I get from this group is light years ahead of what I used to have to pay for. __ Marc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] b64_encode and decode
On Thu, 2008-06-12 at 19:10 -0400, Tom Lane wrote: Marc Munro [EMAIL PROTECTED] writes: So, would there be any chance of redefining the base64 functions in encode.c as extern to eliminate this redundancy? It'd only last until the next time Bruce runs his script that static-izes things that aren't used outside their own module ... Hmmm. Does that script look in contrib? If so I'd be happy to provide a patch to eliminate the redundancy there. If not, maybe it could be persuaded to be more inclusive? __ Marc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] How to Sponsor a Feature
On Thu, 2008-06-12 at 19:27 -0400, Greg Smith wrote: On Thu, 12 Jun 2008, Alvaro Herrera wrote: Incidentally, we have minutes from the meeting. Is it OK to publish them openly? There's a set of minutes already up at http://wiki.postgresql.org/wiki/PgCon_2008_Developer_Meeting There was no solution proposed to the escrow problem, nor to allow sponsoring of one feature by multiple independent individuals. Pity, as those are the main things I get asked about. I've been thinking about this a fair amount recently, and it is difficult to figure out how SPI can handle this in reasonable way. SPI can't really at least not for indviduals. It could reasonably do so under the auspice of paying for services, especially if those services can explicitly be tied to the mission of SPI. PGUS and PGEU are probably better suited for this in the future. PGUS for example is going to have the ability to fundraise for grants. A person could then apply for a grant. The grant could be for a TODO item. In reality though, what should happen is we should have a list of companies and consultants that are willing to be paid to implement features, todos and bug fixes. When someone asks they go to a company that they feel comfortable with. Sincerely, Joshua D. Drake -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Options for protocol level cursors
On Jun 12, 2008, at 3:59 PM, Tom Lane wrote: Sure, but if you're willing to use a SQL-level operation on the portal then you could perfectly well declare the cursor at SQL level too. Indeed, but like I said in my initial e-mail:: I know you can use DECLARE, but I believe that this inhibits the driver from being able to select the transfer format for individual columns; it's all binary or it's all text. Also, I don't think I can DECLARE against a prepared statement, save restating the query, no? Also, the latter has other problems wrt statement parameters. I guess you could prepare(protocol level) the DECLARE, but that seems like a gross workaround as it defeats the purpose of prepared statements by forcing you to create a new statement for each cursor that you plan to open. Of course, unless you can close the existing one before opening the next one. [ I really do hope that I'm missing something, btw :( ] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] b64_encode and decode
Marc Munro [EMAIL PROTECTED] writes: On Thu, 2008-06-12 at 19:10 -0400, Tom Lane wrote: It'd only last until the next time Bruce runs his script that static-izes things that aren't used outside their own module ... Hmmm. Does that script look in contrib? If so I'd be happy to provide a patch to eliminate the redundancy there. Yeah, I believe so --- or at least, the problem would become obvious as soon as it hit the buildfarm. If you can get rid of the duplicative code in contrib/pgcrypto, then by all means patch away. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Options for protocol level cursors
James William Pye [EMAIL PROTECTED] writes: Indeed, but like I said in my initial e-mail:: I know you can use DECLARE, but I believe that this inhibits the driver from being able to select the transfer format for individual columns; it's all binary or it's all text. Huh? I don't see why... you might have such a limitation in a particular driver, but not in the protocol. Also, the latter has other problems wrt statement parameters. I guess you could prepare(protocol level) the DECLARE, but that seems like a gross workaround as it defeats the purpose of prepared statements by forcing you to create a new statement for each cursor that you plan to open. Well, using a query for a cursor is grounds for replanning anyway, because you might want a fast-start plan in such a case. And it's *definitely* grounds for replanning if you are asking for SCROLL capability --- the plan stored for a regular prepared statement very likely can't support that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Better default_statistics_target
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 That was a pretty special case (LIKE/regex estimation), and we've since eliminated the threshold change in the LIKE/regex estimates anyway, so there's no longer any reason to pick 100 as opposed to any other number. So we're still back at what's a good value and why?. Glad to hear that, although I think this is only in HEAD, not backpatched, right? Well at any rate, I withdraw my strong support for 100 and join in the quest for a good number. The anything but 10 campaign. I'm still concerned about the fact that eqjoinsel() is O(N^2). Show me some measurements demonstrating that a deep nest of equijoins doesn't get noticeably more expensive to plan --- preferably on a datatype with an expensive equality operator, eg numeric --- and I'm on board. I hope someone else on the list can do this, because I can't. :) - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200806122054 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkhRxToACgkQvJuQZxSWSsj0OwCfel+zN/jQth79RvIHtxpUefQD APMAmQEKIDS6BzqUjn4eTMzP9NDlxTbE =JZTe -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] default client encoding in postgresql.conf
On Thursday 12 June 2008 17:38:26 Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
looking in my freshly installed 8.3.3, I see this in the postgresql.conf
#client_encoding = sql_ascii# actually, defaults to database
# encoding
Now, certainly initdb can't know for sure what encoding a future database
will be in, but since it does know what encoding template0 friends will
be in, and most databases are copied from those (including encoding),
wouldn't a better default be to set it the encoding of template0?
No. Setting it at all in postgresql.conf is generally the wrong thing;
the right thing is to let the default behavior (ie, make it equal to the
database encoding) happen.
But isn't putting a default that is likely to be wrong just encouraging people
to set it to something more permanent as an attempt to correct this?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] default client encoding in postgresql.conf
Robert Treat [EMAIL PROTECTED] writes: looking in my freshly installed 8.3.3, I see this in the postgresql.conf #client_encoding = sql_ascii# actually, defaults to database # encoding But isn't putting a default that is likely to be wrong just encouraging people to set it to something more permanent as an attempt to correct this? Huh? We *aren't* putting in a default. This conversation is beginning to suggest to me that client_encoding shouldn't be listed in postgresql.conf at all. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Options for protocol level cursors
On Jun 12, 2008, at 4:45 PM, Tom Lane wrote: Huh? I don't see why... you might have such a limitation in a particular driver, but not in the protocol. Oh? I know when you bind a prepared statement you have the ability state the formats of each column, but I'm not aware of the protocol's capacity to reconfigure the formats of an already existing cursor; ie, a DECLARE'd cursor. I know you can use the Describe message to learn about the cursor's column types and formats Got a link to the part of the protocol docs describing this feature? Also, the latter has other problems wrt statement parameters. I guess you could prepare(protocol level) the DECLARE, but that seems like a gross workaround as it defeats the purpose of prepared statements by forcing you to create a new statement for each cursor that you plan to open. Well, using a query for a cursor is grounds for replanning anyway, because you might want a fast-start plan in such a case. And it's *definitely* grounds for replanning if you are asking for SCROLL capability --- the plan stored for a regular prepared statement very likely can't support that. Ah, that is good to know. Thanks. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Overhauling GUCS
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Really? I'm the opposite: I never leave a client's setting at 10, that's just asking for trouble. Making it 100 *after* you encounter problem queries is reactive; I prefer being proactive. Have you ever measured the system speed before and after? Yes. No change (see below on caching) or faster (better plans). Nor is a setting of 10 perfectly adequate: What percentage of your plans actually change with the larger statistics? How many for the better? How many were massively improved? It matters not if there is a slight increase in planning time: the penalty of choosing a Bad Plan far outweighs any increased analyze or planning cost, period. Are you arguing that 10 is a good default, or just against larger values in general? I suspect you're looking at some single-digit percentage slowdown for planning across the board. In exchange if you a) have simple queries you probably see none improving. If you b) have moderately complex queries you probably get some single-digit percentage of them with improvements. And if you c) have very complex queries you probably have a handful of them which see massive improvements. Across the internet there are a whole lot more applications of type (a) than the others... I'm still skeptical that it's the case, but I wouldn't mind seeing some figures about how slowed down a simple database gets going from 10 to 100 (or larger). Robert, any chance we can use Pagila for some sort of test for that? Frankly, I'd be shocked if there is any significant difference and all compared to the actual query run time. Well you might start preparing to be shocked. Note that retrieving the statistics is a query itself so it's not hard for it to be comparable to a similarly simple query. It's not hard for a simple query using multiple columns to be using more records of statistics than it is from the actual data. And things can look much worse if that data is TOASTed and requires further lookups and/or decompression... Even if all you say above is true, and I think we'll have to agree to disagree on that, there's an important point to remember: query plans can be (and very often are) cached. Queries and query results cannot (although I'm working on that... :) Plans to queries is a 1-N, where N can be very, very large, and further boosts the query time vs planning time ratio. ... 100 is no longer a magic threshold for LIKE queries (in CVS HEAD) That's great, but doesn't help existing releases (unless that was backpatched, but I don't recall it if so) But that's a battle I'm going to stop fighting, and concentrate on helping to find a replacement for 10 that may or may not be 100. - -- Greg Sabino Mullane [EMAIL PROTECTED] End Point Corporation PGP Key: 0x14964AC8 200806122100 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkhRyXIACgkQvJuQZxSWSshZpwCeOdLZCu0gSQGpOLciQ6H29Tsd iNgAn3AuoisE8zSbMjLuDL4aWzP6NAth =ujTa -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Overhauling GUCS
You guys call this simplification? You're out of your minds. This proposal is ridiculously complicated, and yet it still fails even to consider adjusting non-numeric parameters. And what about things that require more than a trivial arithmetic expression to compute? It's not hard at all to imagine wanting log, sqrt, etc. We do not need to put computational capability into GUC. Any computations needed to determine a parameter setting should be done by a wizard. +1 (save the comment speculating about anyone's location relative to their mind ;) Additionally, obvious as it may be, there's nothing stopping anyone from developing a tool to generate the configuration file from a more interesting source. Whether that's XML or some DSL that supports computations, doesn't matter. I would think if such a tool showed dramatic merit it would provoke another discussion about core integration, but ISTM that leaving it dead simple is best. [mm, hook into the postgres startup script, shouldn't be that hard to administer..] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] default client encoding in postgresql.conf
On Thursday 12 June 2008 21:11:57 Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
looking in my freshly installed 8.3.3, I see this in the
postgresql.conf #client_encoding = sql_ascii# actually,
defaults to database # encoding
But isn't putting a default that is likely to be wrong just encouraging
people to set it to something more permanent as an attempt to correct
this?
Huh? We *aren't* putting in a default.
Right, but when you look in the postgresql.conf, it looks like we are setting
the default to sql_ascii (since all other default values follow this
commented setting formula).
This conversation is beginning to suggest to me that client_encoding
shouldn't be listed in postgresql.conf at all.
Yeah, that sure seems better than what we currently have.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] default client encoding in postgresql.conf
Robert Treat wrote: This conversation is beginning to suggest to me that client_encoding shouldn't be listed in postgresql.conf at all. Yeah, that sure seems better than what we currently have. I should have thought there was a good argument for preventing its being set in postgresql.conf. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
