Re: [HACKERS] 8.2 beta blockers

All, Is UserLocks a cool enough feature to be worth mentioning in the 8.2 PR? If so, can someone explain it to me off-list? I still don't get what it does ... -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP

Re: [HACKERS] 8.2 beta blockers

refactored code and cleaned up API -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [HACKERS] pg_upgrade: downgradebility

that might end up being the same code. Supposedly someone from EnterpriseDB is working on this as well; where are you? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send

Re: [HACKERS] Units in postgresql.conf.sample

Peter, #work_mem = 1024# min 64, size in kB becomes #work_mem = 1MB # min 64kB (The native units are of course still shown in the documentation for reference.) +1 -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco

Re: [HACKERS] advisory locks and permissions

in a DOS, even without advisory locks ... -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [HACKERS] Release Notes: Major Changes in 8.2

Bruce, What happened to PL/pgSQL debugging? Did it die? -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining

Re: [HACKERS] Release Notes: Major Changes in 8.2

useful? Second question: are the Advisory Locks actually a unique PostgreSQL feature, or are these something other databases already have? --Josh Berkus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] pg_upgrade: downgradebility

others interested in contributing. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do

Re: [HACKERS] pg_upgrade: downgradebility

is whether this is EDB freeware or a real community OSS effort. I think that we'll be happy to have either, but right now it's in some grey area. --Josh Berkus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send

Re: [HACKERS] pg_upgrade: downgradebility

? --Josh Berkus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [HACKERS] 8.3 Development Cycle

will get worse with time). Heck, I have former clients who are still running 7.2. Why would they upgrade? It's never been down, and it's not exposed to untrusted users. --Josh Berkus ---(end of broadcast)--- TIP 9: In versions below 8.0

Re: [HACKERS] 8.3 Development Cycle

Tom, I'm obviously thinking of enums which was ready (for review at least) a few weeks ago, but has probably bitrotted slightly since then given the number of patches that have landed in the tree. I intended to brush it up as soon as the 8.3 tree was open and resubmit it. Will that be a waste

Re: [HACKERS] 8.3 Development Cycle

Tom, Pretty sure. :) Why the oops? They haven't been mentioned in some PR material or something have they? No, I'd just been confused and thought the patch was submitted before feature freeze. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end

Re: [HACKERS] Release Notes: Major Changes in 8.2

not sure what else to list. Suggestions welcome. --Josh Berkus ---(end of broadcast)--- TIP 6: explain analyze is your friend

[HACKERS] Please to technical check of upcoming release

All, Here: http://pgfoundry.org/docman/view.php/147/233/release82.zip is a zip file of a draft of the PostgreSQL 8.2 release and accompanying press kit. Please check if the technical details are correct, and get back to me with any corrections by Thursday. Thanks! -- --Josh Josh Berkus

Re: [HACKERS] Please to technical check of upcoming release

Tom, Thursday? My, we're feeling optimistic about the length of the beta period, aren't we? It takes me a minumum of 2 weeks (preferably 3) to deal with the translations. If we stay on schedule, I'll be *just* ready for a 1-month beta. -- --Josh Josh Berkus PostgreSQL @ Sun San

Re: [HACKERS] horo(r)logy test fail on solaris (again and solved)

the expert. Maybe Jignesh? --Josh Berkus ---(end of broadcast)--- TIP 1: 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

Re: [HACKERS] horo(r)logy test fail on solaris (again and solved)

Zdenek, Hmmm ... we're not using the -fast option for the standard PostgreSQL packages. Where did you start using it? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner

Re: [HACKERS] Faster StrNCpy

? Presumably you mean for 8.3? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your

Re: [HACKERS] JAVA Support

authentication methods, of which GSSAPI is one. So in theory someone from Sun should be looking at coding this. Josh Berkus PostgreSQL @ Sun San Francisco 415-752-2500 ---(end of broadcast)--- TIP 4: Have you searched our list archives

Re: [HACKERS] JAVA Support

, in theory GSSAPI is supposed to support multiple authentication back-ends (ldap, liberty, etc.), but I personally have never seen support for anything but Kerberos. Josh Berkus PostgreSQL @ Sun San Francisco 415-752-2500 ---(end of broadcast)--- TIP

Re: [HACKERS] JAVA Support

methods. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Per-database search_path

by connecting. Yes. I've been bitten by this more than once ... However, it almost seems like this would become a piece of the other per-database-user stuff we'd like to do, like local superuser. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast

[HACKERS] Select for update with outer join broken?

         at   com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.throwJDOSql Exception(SQLStoreManager.java:632) This was working per SQL spec before beta ... what happened? Error above is from Thursday's snapshot. -- Josh Berkus PostgreSQL @ Sun San Francisco

Re: [HACKERS] Select for update with outer join broken?

, this was working using the snapshot from about a month ago. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's

Re: [HACKERS] Select for update with outer join broken?

Tom, But did it ever work against a release? The backend's test code for this was busted for awhile during 8.2devel. No, because SQL-standard correct SELECT FOR UPDATE outer join is an 8.2 feature. We didn't have it in 8.1. -- Josh Berkus PostgreSQL @ Sun San Francisco

Re: [HACKERS] Select for update with outer join broken?

is expected by the J2EE certification, so it's at least somewhat industry-standard. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [HACKERS] Faster StrNCpy

Tom, FWIW, Tom Daly did some SpecJAppserver runs on the latest snapshot and didn't show any reduction in text parsing overhead. Unfortunately, he's gone on vacation now so I can't get details. I'm going to try to set up some tests using TPCE to see if it's affected. --Josh

Re: [HACKERS] Updated version of FAQ_Solaris

Zdenek, Bruce, Has anyone updated the Solaris portion of runtime.sgml yet? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] 8.2 translation status?

distribution. I've asked JPUG about this, and haven't been able to get an answer on whether this is reasonable for 8.2. Do you have any idea? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your

Re: [HACKERS] pg_upgrade: downgradebility

Jonah, It's been two weeks, and I haven't seen anything, either here or on pg_foundry. Is this project derailed? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 4: Have you searched our list archives

Re: [HACKERS] Select for update with outer join broken?

didn't check to see that there actually had been a patch. OOops. I will have to find standards documentation on this grey area and hopefully submit something for 8.3. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 1

Re: [HACKERS] pg_dump exclusion switches and functions/types

to go with orderless switching. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do

Re: [HACKERS] Upgrading a database dump/restore

and arguably a real design flaw. directors? (looks around) Nobody here but us chickens, boss. If you're really interested in pg_upgrade, you're welcome to help out. Gavin Sherry, Zdenek, and Jonah Harris are working on it (the last separately, darn it). -- Josh Berkus PostgreSQL @ Sun San

Re: [HACKERS] [PATCHES] Generic Monitoring Framework with DTrace patch

All, I'll be fixing this documentation issue now that I have full information. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose

Re: [HACKERS] timestamp subtraction (was Re: [SQL] formatting intervals with to_char)

changed. Many. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [HACKERS] 8.2beta1 does not compile for me on Solaris 10

Use --without-readline to disable readline support. [EMAIL PROTECTED] ~/postgresql-8.2beta1]$ uname -a SunOS xx 5.10 Generic i86pc i386 i86pc Do you have readline installed? It's not standard on Solaris. I don't know if it's even available from Blastwave. -- --Josh Josh Berkus

Re: [HACKERS] 8.2beta1 does not compile for me on Solaris 10

Joseph, How about just compiling --without-readline? Also, if you have Sun Studio 11 available, you'll get better performance out of your PostgreSQL. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 6: explain

Re: [HACKERS] Index Tuning Features

Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend

[HACKERS] Commitfest has started, y'all

Folks, If you hadn't noticed, the CommitFest started this week. I'm currently assigning patches to reviewers, but if there's a patch you especially want to tackle, please put your name down right away. If you can't actually review the patch *this week*, please don't put your name down.

[HACKERS] Need more reviewers!

, so I can assign them to beginners. Please volunteer now! -- --Josh Josh Berkus PostgreSQL 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] Proposed patch: make SQL interval-literal syntax work per spec

(1) In the spec, an interval value or literal must be either year-month or day-time. (I guess they didn't want to try to deal with the sticky issues of what it means to have an interval of, for example, seven months and three days -- since an interval has no sense of which seven months.)

[HACKERS] Commitfest patches mostly assigned ... status

Hackers, At this point, almost all patches have been assigned to reviewers. If you submitted a patch and don't get feedback by Saturday, take a look at who's in the reviewers column and send them a query. Since I have no way to track when patches are assigned to reviewers, I have no idea if

Re: [HACKERS] Commitfest patches mostly assigned ... status

Josh is probably basing that on the long history of discussion/revision cycles. Yep, and that *I* don't understand what the patch does, so I'm not going to turn a newbie reviewer loose on it. -- --Josh Josh Berkus PostgreSQL San Francisco -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] Where to Host Project

know I put in over 150 hours just making it run. At this point, nobody wants to deal with it anymore. -- --Josh Josh Berkus PostgreSQL San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] Where to Host Project

as much work as fixing it. -- --Josh Josh Berkus PostgreSQL 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] Do we really need a 7.4.22 release now?

the announcement fair (e.g. not December 2008) and loud (e.g. -announce, -general, main page of postgresql.org, press release). I agree, and would be happy to draft such an announcement, as soon as we agree on a date. -- --Josh Josh Berkus PostgreSQL San Francisco -- Sent via pgsql-hackers mailing list

Re: [HACKERS] PostgreSQL future ideas

developers. If the project has a problem right now, it's dealing with the tremendous output of the developers we do have. And infrastructure. -- --Josh Josh Berkus PostgreSQL San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] PostgreSQL future ideas

entirely in-memory over a cluster of anonymous servers. At which point the only thing left of PostgreSQL would be the parser. Hmmm, this is sounding familiar somehow ... -- --Josh Josh Berkus PostgreSQL San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)

possible that the SE and/or multilevel framework could remain parallel-but-different from SQL-level permissions, which would not include data hiding or data substitution. -- --Josh Josh Berkus PostgreSQL San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)

Peter, Yeah, but do we even have the slightest bit of information about what exactly would be required to achieve the required levels? And whether this patch does it? And whether there would be alternative, more desirable ways to achieve a similar level? Actually, I have some direct

Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)

the current status of that evaluation. -- --Josh Josh Berkus PostgreSQL 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] Updates of SE-PostgreSQL 8.4devel patches

Peter, How important is this consistency goal in reality? It's actually the primary point of SE-Linux. Its audience wants a centralized policy manager which applies access policies to everything on the network, regardless of whether it's a file, a port, or a database. Oracle has not

Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches

At the past, I had considered to implement polyinstantiated table as a part of SE-PostgreSQL, but it required us unacceptable scale of changes, so I dropped the idea. The TrustedSolaris folks would like polyinstantiation, but I don't know if they actually have anyone working on Postgres

[HACKERS] September CommitFest Closed

Hackers, As it is now October 1st, I have taken the remaining 5 patches still under discussion and moved them to the top of the list for November, though hopefully they will be applied sooner. For the September commitfest, 29 patches were applied (one to pgFoundry) and 18 patches were sent

Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches

KaiGai, If I can understand correctly, we don't have a clear conclusion of this. So, it is unclear for me whether the row-level permission at SQL level is necessary to progress the reviewing process of SE-PostgreSQL, or not. Can you *do* the row-level permission? -- --Josh Josh Berkus

[HACKERS] WITH RECURSIVE ... simplified syntax?

it be a worth it for us to implement a non-standard simple syntax sugar on top of WITH RECURSIVE? Or, at least, something like CONNECT_BY()? -- --Josh Josh Berkus PostgreSQL San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] How is random_page_cost=4 ok?

I don't think random_page_cost actually corresponds with any real number anymore. I just treat it as an uncalibrated knob you can turn and benchmark the results at. And, frankly, not a useful knob. You get much more useful results out of effective_cache_size and cpu_* costs than you get

[HACKERS] Contrib, schema, and load_module

and pgcrypto? 2) how do we give DBAs an easy search path for the simplest case, where they want all users to have access to all loaded modules? 3) what work was actually done on load_module() by Tom Dunstan, which might make this unnecessary? --Josh Berkus -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Contrib, schema, and load_module

Alvaro Herrera wrote: Josh Berkus wrote: 3) what work was actually done on load_module() by Tom Dunstan, which might make this unnecessary? http://archives.postgresql.org/message-id/[EMAIL PROTECTED] This link appears on Todo: Improve the module installation experience (/contrib, etc

[HACKERS] The Axe list

Folks, It's that time again! Purging antiquated contrib modules. chkpass: this module is incomplete and does not implement all functions it describes. It's not really even useful as an Example since it uses crypt() and not any modern encryption. And Darcy hasn't touched it in 6 years.

Re: [HACKERS] The Axe list

D'Arcy, However, if all it needs is a modern encryption scheme that's probably an hour's work. The only reason that I haven't done so yet is because I have no use case. Well, I had no use case either which is why I didn't propose updating it. I can certainly see having chkpass live on

Re: [HACKERS] The Axe list

All, So it sounds like intagg is still in use/development. But ... is it more of an example, or is it useful as a type/function in production? --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] WITH RECURSIVE ... simplified syntax?

Tom Lane wrote: Josh Berkus [EMAIL PROTECTED] writes: Would it be a worth it for us to implement a non-standard simple syntax sugar on top of WITH RECURSIVE? Or, at least, something like CONNECT_BY()? The Oracle syntax only *looks* simple. When you start to study it you realize that it's

Re: [HACKERS] Contrib, schema, and load_module

Tom, Yeah. If the schema-per-module answer were really a good answer, we'd have done it before now. But you need more infrastructure than just a schema to get good things to happen. Aside from the search-path-hell issue, a schema alone doesn't solve the problem of persuading pg_dump to dump

Re: [HACKERS] Contrib, schema, and load_module

Dimitri, Am I correct in assuming, however, that you're not at all likely to complete this for 8.4? --Josh -- 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] Cross-column statistics revisited

Josh Berkus PostgreSQL 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] Cross-column statistics revisited

like this are actually a problem in practice. My experience is that any estimate which is more than 5x wrong (i.e. .2 or 5.0) usually causes problems, and 3x sometimes causes problems. -- --Josh Josh Berkus PostgreSQL San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] So what's an empty array anyway?

blank. It's a defect of the Timestamp type (and a few others) that it doesn't have a standard zero value -- the typical tri-value NULL problem. I do agree that we ought to support multi-dimensional empty arrays for consistency. However: is '{}' = '{}{}' or not? -- --Josh Josh Berkus

Re: [HACKERS] Bitmap Indexes: request for feedback

patch as it stood in 2007 was that performance just wasn't that much faster than a btree, except for specific corner cases. Otherwise, someone else would have been interested enough to pick it up and finish it. So performance testing of the patch is absolutely essential. -- --Josh Josh Berkus

Re: [HACKERS] So what's an empty array anyway?

Simon, I meant the dimension of {} should be NULL. Oh, so array_dims(1, '{}') IS NULL? I'm not entirely satisfied with that, but other solutions are just as bad. --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

[HACKERS] Reminder: only 10 days until final CommitFest

! --Josh Berkus -- 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] Reminder: only 10 days until final CommitFest

trying to get us closed out before Christmas. ;-) -- --Josh Josh Berkus PostgreSQL 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

[HACKERS] psql Feature request \set query

-c SELECT now();` ... provided you were willing to parse out the garbage in the output. This seems inconsistent, and it seems like the ability to store the results of a single-row-returning query in a psql variable would be useful for testing. yes/no? -- --Josh Josh Berkus PostgreSQL San

Re: [HACKERS] psql Feature request \set query

with me. -- --Josh Josh Berkus PostgreSQL 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] psql Feature request \set query

Everyone, What people asking for psql scriptability really want, in my estimate, is the ability to write SQL plus some control structures anywhere, in the server, in the client, or so that they don't have to know where. Commercial vendors have that: Oracle has PL/SQL as server-side language

[HACKERS] Please make sure your patches are on the wiki page

Patch submitters, Please make sure your patches are on the November CommitFest wiki page, with correct and updated links. http://wiki.postgresql.org/wiki/CommitFest_2008-11 -- Josh Berkus PostgreSQL San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Please make sure your patches are on the wiki page

Robert, (1) moving all of the patches committed prior to 11/1 to a separate section or page Why? (2) sorting the pending patches by complexity or subject matter Sorting them by complexity would be great, if I thought I could do it. I'm not sure I can. -- Josh Berkus PostgreSQL San

Re: [HACKERS] Please make sure your patches are on the wiki page

others have too. Actually, I'd really like it if you and the other advanced hackers ignored the simple patches. I've got a list of 6 new reviewers, and I'd like to be able to give them those patches to review -- they generally can't help with the hard ones. -- Josh Berkus PostgreSQL San

[HACKERS] Mail troubles, stand by

about something important, please cc [EMAIL PROTECTED] as well. Josh Berkus PostgreSQL San Francisco 415-752-2500 -- 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] Please make sure your patches are on the wiki page

Stephen, what is the status of your efforts? The latest one I could found is the colprivs_wip.20080902.diff.gz. Do you have any updated one? Snowman told me this week that he was working hard on it -- he declined to be a reviewer for that reason. --Josh -- Sent via pgsql-hackers mailing

Re: [HACKERS] Well done, Hackers

Tom, Robert, Simon, What, are people just on edge because of the US election? It looks to me like the commitfest system is going really well. Of course, we'll see how long it takes to close out 8.4. But I think we're in much better shape than we were for 8.3. We're even in better shape to

Re: [HACKERS] Simple postgresql.conf wizard

Greg Smith wrote: While I've got a pretty clear vision for what I'm doing with this next and will kick off a pgfoundry project real soon, I wanted to throw this out as a WIP for feedback at this point. I was ultimately hoping to one day have something like this shipped as a contrib/ module to

Re: [HACKERS] Where to point CommitFestOpen?

Tom, Thoughts, better ideas? Nope, that's why I ignored CommitFestOpen. I couldn't figure out where to point it. Note that I'm going to propose replacing the wiki with real software come 8.5. The wiki method confuses new reviewers, and makes me spend about 500% as much time managing

Re: [HACKERS] My review for the patch Table command

Unicron, 4. Since it is just an alternative to select * from Table, I think this feature is unneccessary. Heh. I agree, but tell that to the SQL committee. I don't think we need to argue out the merits of adding standard syntax. This patch is Ready for Code Review. --Josh --

[HACKERS] Final /contrib cleanup -- yes/no?

All, Looking at my old thread I realized I never got an answer on whether people agreed with these two items: 1) Take the SET search_path=public out of all contrib SQL scripts so that DBAs can determine the correct schema by using PGOPTIONS. 2) Add BEGIN/COMMIT to all SQL scripts. --Josh

Re: [HACKERS] Final /contrib cleanup -- yes/no?

Tom, I don't recall that having been proposed, and I don't think it's really a good idea. We intentionally put those SETs in, not that long ago. I haven't been able to find any reasoning on any list why those SETs where a good idea. Bruce put them in, but apparently without discussion.

Re: [HACKERS] Final /contrib cleanup -- yes/no?

Joshua D. Drake wrote: On Thu, 2008-11-06 at 17:24 -0500, Tom Lane wrote: Josh Berkus [EMAIL PROTECTED] writes: The way the SQL scripts currently work, there is no way to manage what schema the contrib modules get built in *except* to edit the scripts. Right, that's the intended

Re: [HACKERS] SQL5 budget

Chris Browne wrote: [EMAIL PROTECTED] (Jonah H. Harris) writes: On Sun, Nov 9, 2008 at 7:41 PM, Decibel! [EMAIL PROTECTED] wrote: I think you're barking up the wrong tree here; the community can't really do hacking for hire. If you want to pay for something to be implemented (which is great!),

Re: [HACKERS] SQL5 budget

Josh, I would note that the individual has been hitting *everyone* directly and via list. So either he is quite serious, doesn't understand etiquette or is a spammer. I think there is a language barrier at work. --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] Simple postgresql.conf wizard

Greg, Attached version takes all its input via command line switches. If you don't specify an explict number of connections, it also implements setting max_connections via some of the logic from your calcfactors spreadsheet. OK, I'll review. What follows is a review of the *previous*

Re: [HACKERS] Simple postgresql.conf wizard

Gregory Stark wrote: Josh Berkus [EMAIL PROTECTED] writes: DW: default_statistics_target = 400 Mixed: default_statistics_target = 100 You, my friend, are certifiably insane. Hmmm? Why? I've used those settings in the field, fairly frequently. I was actually wondering

Re: [HACKERS] Simple postgresql.conf wizard

Greg, BTW, I think this is still in enough flux that we really ought to make it a pgfoundry project. I don't think we'll have anything ready for 8.4 contrib. --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] SQL5 budget

Josh, Actually that is a poorly worded page. It really should be something like, How to submit a patch or How to get your patch committed. Yeah, I told Bruce I was going to re-write that page but seem to have been short some Round Tuits. --Josh -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Simple postgresql.conf wizard

Tom, Even though we all agree default_statistics_target = 10 is too low, proposing a 40X increase in the default value requires more evidence than this. In particular, the prospect of a 1600-fold increase in the typical cost of eqjoinsel() is a mite scary. It's a *completely* acceptable

Re: [HACKERS] Simple postgresql.conf wizard

Simon, In any case, saying that somebody is certifiably insane in a public forum is at best questionable. I would like to see the comment withdrawn. Thanks for defending me. I think Greg threw that at me because he knows I'm very difficult to offend, though. I assume that Greg wouldn't make

Re: [HACKERS] Simple postgresql.conf wizard

Greg, To give you an idea how overdiscussed this general topic is, I just sent a message to Josh suggesting we might put database size into tiers and set some parameters based on that. Guess what? That was his idea the last time around, I subconsciously regurgitated it:

Re: [HACKERS] On-list behavior WAS: Simple postgresql.conf wizard

Simon, Stark, others: It seems a strange moderation policy that allows bald insults from some people but not others. And stranger still that you think you should leap to the defence of any person making them. If the comments were meant so lightly, it would seem easy to withdraw them also, with

[HACKERS] TODO list request: FK to unique expression indexes

, no? --Josh Berkus -- 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_stats_target WAS: Simple postgresql.conf wizard

expect increasing DST to have little effect. The databases where higher DST is useful is ones with skewed data distribution. Unfortunately, all the data examples I could point to are proprietary customer databases :-( -- --Josh Josh Berkus PostgreSQL San Francisco -- Sent via pgsql-hackers

<    6   7   8   9   10   11   12   13   14   15   >