Re: [PATCHES] updated hash functions for postgresql v1

Dear PostgreSQL developers,

I am re-sending this to keep this last change to the
internal hash function on the radar.

Ken
............
Sorry about the delay for this update to the new hash
index implementation. I was trying to get the WAL logging
in place and forgot to post the actual patch. The WAL
for hash indexes will need to wait for 8.5, but I did
want to add back in the piece of the Bob Jenkins 2006
hash function that was stripped out of the initial
patch on application due to concerns about the randomness
of the resulting hash values. Here is a re-post of my
initial findings comparing the old/new Jenkins hash
from lookup2 and lookup3. I have added a third column
containing the results for the hash_any() resulting
from the attached patch as well as simple timing test
for a DB reindex both before and after patching.

Also attached is a simple documentation patch updating
the note attached to the hash index description.

Regards,
Ken
----------------------------------------------------
Hi,

I have finally had a chance to do some investigation on

Re: [PATCHES] updated hash functions for postgresql v1

Sorry about the delay for this update to the new hash
index implementation. I was trying to get the WAL logging
in place and forgot to post the actual patch. The WAL
for hash indexes will need to wait for 8.5, but I did
want to add back in the piece of the Bob Jenkins 2006
hash function that was stripped out of the initial
patch on application due to concerns about the randomness
of the resulting hash values. Here is a re-post of my
initial findings comparing the old/new Jenkins hash
from lookup2 and lookup3. I have added a third column
containing the results for the hash_any() resulting
from the attached patch as well as simple timing test
for a DB reindex both before and after patching.

Also attached is a simple documentation patch updating
the note attached to the hash index description.

Regards,
Ken
----------------------------------------------------
Hi,

I have finally had a chance to do some investigation on
the performance of the old hash mix() function versus
the updated mix()/final() in the new hash function. Here
is a table of my current results for both the old and the
new hash function. In this case cracklib refers to the
cracklib-dict containing 1648379 unique words massaged
in various ways to generate input strings for the hash
functions. The result is the number of collisions in the

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 <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

libpq not linked against libgssapi

src/interfaces/libpq/Makefile is missing a reference to libgssapi.
The problem occurred while compiling 8.3.3 on NetBSD --with-gssapi,
and is still present in HEAD. A patch is attached.

Index: src/interfaces/libpq/Makefile
===================================================================
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/Makefile,v
retrieving revision 1.167
diff -b -u -r1.167 Makefile
--- src/interfaces/libpq/Makefile	17 Sep 2008 04:31:08 -0000	1.167
+++ src/interfaces/libpq/Makefile	1 Oct 2008 13:57:49 -0000
@@ -56,7 +56,7 @@
 # shared library link.  (The order in which you list them here doesn't
 # matter.)
 ifneq ($(PORTNAME), win32)
-SHLIB_LINK += $(filter -lcrypt -ldes -lcom_err -lcrypto -lk5crypto -lkrb5 -lgssapi_krb5 -lgss -lssl
-lsocket -lnsl -lresolv -lintl, $(LIBS)) $(LDAP_LIBS_FE) $(PTHREAD_LIBS)
+SHLIB_LINK += $(filter -lcrypt -ldes -lcom_err -lcrypto -lk5crypto -lkrb5 -lgssapi_krb5 -lgss
-lgssapi -lssl -lsocket -lnsl -lresolv -lintl, $(LIBS)) $(LDAP_LIBS_FE) $(PTHREAD_LIBS)
 else
 SHLIB_LINK += $(filter -lcrypt -ldes -lcom_err -lcrypto -lk5crypto -lkrb5 -lgssapi32 -lssl -lsocket
-lnsl -lresolv -lintl $(PTHREAD_LIBS), $(LIBS)) $(LDAP_LIBS_FE)
 endif

--

-- 
Sent via pgsql-patches mailing list (pgsql-patches <at> postgresql.org)
To make changes to your subscription:

Infrastructure changes for recovery (v8)

Patch now includes all previous agreed changes, plus I've found what
looks to be a workable method of removing the shutdown checkpoint
without loss of robustness. 

Patch summary

Tuning 
* Bgwriter performs dirty block cleaning during recovery
* Bgwriter performs restartpoints, offloading this task from Startup
process to allow it to continue with recovery actions 
* Shutdown checkpoint removed at end of recovery. Bgwriter performs
immediate checkpoint instead, so we have same protection, but
connections and transactions can be started earlier than previously.
* PreAllocXLogs() not performed by startup process, so we do not delay
startup while we write zeroes to next WAL file. bgwriter does that now.
* XLogCtl structure padding for enhanced scalability

Recovery State Changes
* If archive recovery proceeds past a safe stopping point we signal the
postmaster that database is now in a consistent state, PM_RECOVERY. This
state change is also linked to startup of the bgwriter and stats
processes (and will in the future be the place where read only backends
may connect also)
* optional recovery_safe_start_location parameter now provided in
recovery.conf, to allow a consistency point to be manually defined if a
base backup was not taken using standard pg_start/stop backup functions
* New minSafeStopPoint added to controlfile to allow us to determine
consistency if archive recovery crashes/restarts. Value is updated each
time we access new WAL file.
* stats file removed earlier in recovery, so we may accumulate new stats

Re: hash index improving v3

Simon Riggs <simon <at> 2ndQuadrant.com> writes:
> Thinks: Why not just sort all of the time and skip the debate entirely?

The sort is demonstrably a loser for smaller indexes.  Admittedly,
if the index is small then the sort can't cost all that much, but if
the (correct) threshold is some large fraction of shared_buffers then
it could still take awhile on installations with lots-o-buffers.

The other side of that coin is that it's not clear this is really worth
arguing about, much less exposing a separate parameter for.

			regards, tom lane

--

-- 
Sent via pgsql-patches mailing list (pgsql-patches <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PgFoundry] Unsigned Data Types [1 of 2]

Message Resend.

I forgot to spit the attachments so they did not make it through the list.

Patch 1 of 2 : Base uint type.
Patch 2 of 2 : Regression tests.

- Ryan

On Mon, Sep 15, 2008 at 8:13 AM, Ryan Bradetich <rbradetich <at> gmail.com> wrote:
> Hello Jaime,
>
> I have the code and regression tests updated to solve the problems you initially
> discovered.  After code reading, stepping through with the debugger, and
> help from RhodiumToad on irc I was able to implement new restrict
> selective estimation
> functions for the uint4 vs int4 data types.  The uint1 vs int4 and
> uint2 vs int4 data
> types did not require a custom restrict selective estimation function.
>
> Here is an updated base and tests tar packages with these changes in place.  I
> still have better code comments on my TODO list.  I wanted to get
> updated code out
> to see if there are other problems the unsigned data type fails to
> address properly.
>
> I will work on better commenting the code tonight and tomorrow.
>
> Thanks again for your review and testing!
>

Re: [PgFoundry] Unsigned Data Types [1 of 2]

On 9/15/08, Ryan Bradetich <rbradetich <at> gmail.com> wrote:
> Hello Jaime,
>
> I have the code and regression tests updated to solve the problems you initially
> discovered.

great, i will test during this week...

-- 
regards,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. (593) 87171157

--

-- 
Sent via pgsql-patches mailing list (pgsql-patches <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Solve a problem of LC_TIME of windows.

Hi.

I have problem of LC_TIME of windows.(CVS-HEAD)

As for Version 8.3.3. It is edited by wrong gettext and is. (But, it is expressed.)
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/pg8.3.3-to_char_gettext_format.png

As for Version 8.4. It came to be used by Tom-san in strftime of Native-windowsAPI.
It is good improvement.! But, strftime of Native returns a result by CODEPAGE of
environment of operation by Windows with LC_TIME. In Japanese environment, return
value is SJIS(CP932). Then, SJIS(CP932) can't be chosen by SERVER_ENCODING.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/pg84beta-03-to_char.png

Then, I'm proposal patch. It is solved splendidly.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/DATECHECK_EUCJP.txt
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/DATECHECK_UTF8.txt

Regards,
Hiroshi Saito 

--

-- 
Sent via pgsql-patches mailing list (pgsql-patches <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

libpq events patch (with sgml docs)

- Added sgml docs.
- Removed the PQpassThroughData and PQresultPassThroughData functions.
- Added an argument to PGEventProc, the passThrough pointer.
- fixed some errors in the code comments due to code shuffles.

-- 
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/

Index: doc/src/sgml/libpq.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/libpq.sgml,v
retrieving revision 1.260
diff -C6 -r1.260 libpq.sgml
*** doc/src/sgml/libpq.sgml	27 Jun 2008 02:44:31 -0000	1.260
--- doc/src/sgml/libpq.sgml	5 Sep 2008 19:00:56 -0000
***************
*** 2092,2103 ****
--- 2092,2222 ----
          Note that <function>PQclear</function> should eventually be called
          on the object, just as with a <structname>PGresult</structname>
          returned by <application>libpq</application> itself.
         </para>
        </listitem>
       </varlistentry>
+ 

still alive?

I thought -patches was supposed to die. What happened?

-- ams

--

-- 
Sent via pgsql-patches mailing list (pgsql-patches <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches