Re: [HACKERS] [GENERAL] 8.2.3: Server crashes on Windows using Eclipse/Junit

Trevor Talbot wrote: > On 10/17/07, Magnus Hagander <[EMAIL PROTECTED]> wrote: >> On Wed, Oct 17, 2007 at 02:40:14AM -0400, Tom Lane wrote: > >>> Maybe we should put an #ifdef WIN32 into guc.c to limit max_connections >>> to something we know the platform can stand? It'd be more comfortable >>> i

Re: [HACKERS] Hash index todo list item

Kenneth, I just pushed the revised patch (v2!). The revised approach samples the parent relation to estimate the number of tuples rather than performing a complete scan. In my tests, the estimate appears to be accurate, erring on the larger side, which is fine. Tom, That is great. I am loo

Re: [HACKERS] Hash index todo list item

Tom, Thank you for the update. I am currently working on updating the patch Neil Conway sent in against 8.0-ish that stores only the hash in the index and locates the entries within the page using a binary search. Then I will fold in your recent update. On Sun, Oct 21, 2007 at 01:13:48PM -0700, T

[HACKERS] Latin vs non-Latin words in text search parsing

If I am reading the state machine in wparser_def.c correctly, the three classifications of words that the default parser knows are lword Composed entirely of ASCII letters nlword Composed entirely of non-ASCII letters (where "letter" is defined by iswalpha()) wor

Re: [HACKERS] Latin vs non-Latin words in text search parsing

Tom Lane wrote: > ISTM that perhaps a more generally useful definition would be > > lword Only ASCII letters > nlwordEntirely letters per iswalpha(), but not lword > word Entirely alphanumeric per iswalnum(), but not nlword > (hence, includes at leas

Re: [HACKERS] Latin vs non-Latin words in text search parsing

Alvaro Herrera <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> ISTM that perhaps a more generally useful definition would be >> >> lwordOnly ASCII letters >> nlword Entirely letters per iswalpha(), but not lword >> word Entirely alphanumeric per iswalnum(), b

Re: [HACKERS] Ready for beta2?

Bruce Momjian wrote: We have had very few beta1 issues. I am thinking we should release beta2 next week and perhaps accelerate beta and consider a final release in November rather than December. Because of the length of our feature freeze it is possible we are not going to have as many beta bug

Re: [HACKERS] MVCC, undo log, and HOT

Bruce Momjian wrote: Those who have been with the community from long ago might remember discussion about implementing a undo log. The big advantage of this is that it allows UPDATE to _replace_ rows and limits the amount of cleanup required for UPDATEs. I am hoping that with HOT we will no lon

Re: [HACKERS] Ready for beta2?

Josh Berkus wrote: > Bruce Momjian wrote: > > We have had very few beta1 issues. I am thinking we should release > > beta2 next week and perhaps accelerate beta and consider a final release > > in November rather than December. Because of the length of our feature > > freeze it is possible we are

Re: [HACKERS] MVCC, undo log, and HOT

Josh Berkus wrote: Bruce Momjian wrote: Those who have been with the community from long ago might remember discussion about implementing a undo log. The big advantage of this is that it allows UPDATE to _replace_ rows and limits the amount of cleanup required for UPDATEs. I am hoping that wit

Re: [HACKERS] Ready for beta2?

Bruce Momjian wrote: Josh Berkus wrote: Bruce Momjian wrote: We have had very few beta1 issues. I am thinking we should release beta2 next week and perhaps accelerate beta and consider a final release in November rather than December. Because of the length of our feature freeze it is possible

[HACKERS] Rethinking ts_debug() output

I hadn't realized till just now that ts_debug()'s output is not compatible with the way the function was defined in 8.2 contrib. But since apparently backwards-compatibility is not a controlling factor here, I have a couple suggestions: * It seems like a bad idea to merge the controlling-dictionar

Re: [HACKERS] Ready for beta2?

"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > Bruce Momjian wrote: >> Nothing motivates people to test more than moving toward RC1. ;-) > Getting Beta2 out is vital to actually getting people to test there are > known issues and changes with Beta1 that have made it pretty much a > useless Bet

Re: [HACKERS] Ready for beta2?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Sunday, October 21, 2007 22:38:04 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > I've posted notes over the past few days about half a dozen relatively- > minor-but-none-the-less-initdb-forcing issues in tsearch. We have to > either fix those o

Re: [HACKERS] Ready for beta2?

"Marc G. Fournier" <[EMAIL PROTECTED]> writes: > On Sunday, October 21, 2007 22:38:04 -0400 Tom Lane <[EMAIL PROTECTED]> > wrote: >> I've posted notes over the past few days about half a dozen relatively- >> minor-but-none-the-less-initdb-forcing issues in tsearch. We have to >> either fix those o

Re: [HACKERS] Rethinking ts_debug() output

2007/10/22, Tom Lane <[EMAIL PROTECTED]>: > I hadn't realized till just now that ts_debug()'s output is not > compatible with the way the function was defined in 8.2 contrib. > But since apparently backwards-compatibility is not a controlling > factor here, I have a couple suggestions: > > * It see

Re: [HACKERS] Ready for beta2?

> > - --On Sunday, October 21, 2007 22:38:04 -0400 Tom Lane <[EMAIL PROTECTED]> > wrote: > > > I've posted notes over the past few days about half a dozen relatively- > > minor-but-none-the-less-initdb-forcing issues in tsearch. We have to > > either fix those or decide we're not going to fix them

Re: [HACKERS] Including Snapshot Info with Indexes

Hi, I have tested with makeing this change and it is showing useful readings. The point of introducing the indexes with snapshot is that it should reduce the number of logical I/Os.(It may be from memory / from hard disk). Logical I/Os are potential Physical I/Os. On 10/20/07, Martijn van Oo