SEO

Compiled fine. Still a few warnings (using Fedora Core 6 / AMD64).

The new PG_MAGIC_MODULE requirement threw me for a loop. I expect it
will catch others off guard as well.

One of my complicated queries that I threw at it seems to run about
10% - 20% faster now, which is pretty sweet.

The multiline wrap text editor in psql works really well, except it
seems to screw up if I resize the terminal. If I restore the terminal
to its original size, and refresh, it fixes itself.

I'm using it on one of my productions system now, and nothing has
failed yet. :-)

I'm pretty happy.

Good job people.

Cheers,
mark

--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
.. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Sun, Nov 05, 2006 at 01:15:51AM -0500, mark@mark.mielke.cc wrote:
> One of my complicated queries that I threw at it seems to run about
> 10% - 20% faster now, which is pretty sweet.

I take this back. I forgot to 'analyze'. After 'analyze', the times
returned to the slower 8.1 times. :-(

I will have to investigate. The generated plan is more complex after
'analyze'...

Cheers,
mark

--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
.. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

On Sun, 2006-11-05 at 01:15 -0500, mark@mark.mielke.cc wrote:

> The new PG_MAGIC_MODULE requirement threw me for a loop. I expect it
> will catch others off guard as well.

Did you find the documentation adequate? Could you locate what you
needed to know quickly and accurately? Do you think the change was
adequately explained?

If that hit you then we're gonna get a few more people trip the same
way. Do you have any suggestions as to how to avoid that experience for
others?

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Sun, Nov 05, 2006 at 09:11:07AM +0000, Simon Riggs wrote:
> On Sun, 2006-11-05 at 01:15 -0500, mark@mark.mielke.cc wrote:
> > The new PG_MAGIC_MODULE requirement threw me for a loop. I expect it
> > will catch others off guard as well.
> Did you find the documentation adequate? Could you locate what you
> needed to know quickly and accurately? Do you think the change was
> adequately explained?

The documentation was good - once I checked developer.postgresql.org
for the latest copy.

> If that hit you then we're gonna get a few more people trip the same
> way. Do you have any suggestions as to how to avoid that experience for
> others?

I believe the release notes are inadequate. I've read them three times
before and it never stood out for me.

Currently it is referenced under:

E.1.3.16. Source Code Changes

- Add PG_MODULE_MAGIC header blocks to all shared object files
(Martijn van Ousterhout)

The magic block prevents version mismatches between loadable object
files and servers.


I believe I read this all three times as a "internal PostgreSQL change
for developers only". The PG_MODULE_MAGIC has a wider impact that what
is listed above.

I suspect this should be listed under "Migration to 8.2" or "Server
Changes" as "loadable modules are now required to include PG_MODULE_MAGIC
to protect the server from accidentally loading an incompatible module -
all loadable module authors must implement the change described in the
documentation to allow their loadable modules to work properly in 8.2".

Cheers,
mark

--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
.. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/


---------------------------(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 not
match

On Sun, 2006-11-05 at 01:15 -0500, mark@mark.mielke.cc wrote:
> Compiled fine. Still a few warnings (using Fedora Core 6 / AMD64).

Presumably those are just the standard warnings we can't easiy
eliminate. If not, can you post them please?

-Neil



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Sun, Nov 05, 2006 at 11:01:40AM -0500, Neil Conway wrote:
> On Sun, 2006-11-05 at 01:15 -0500, mark@mark.mielke.cc wrote:
> > Compiled fine. Still a few warnings (using Fedora Core 6 / AMD64).
> Presumably those are just the standard warnings we can't easiy
> eliminate. If not, can you post them please?

They all appear harmless. For the uninitialized warnings, the compiler
is not able to prove that tm2timestamp, numericvar_to_int8, or
cost_bitmap_tree_node always stores to the final argument and does not
fetch from the final argument. An '= 0' would get rid of each of the
warnings, and might simplify some code (that does conditional
assignment to 0), although perhaps the goal is to improve performance
and avoid an assignment to '= 0' if not necessary.

I suspect initialization would have no measurable performance impact,
and would improve the maintainability of the code. One more warning
that people don't become trained to ignore. If tm2timestamp ever
did not assign to the final argument, the value would be zero, and
not random data from the stack.

For the label warning, I think it might be generated by bison/yacc,
and no REJECT rule is used?

I don't know about the nbtinsert.c warnings. It looks like part of a
structure is initialized, and then the structure is used. A little odd.

I've included them all below. Pretty few for an open source project. :-)

Cheers,
mark


gcc -O3 -march=athlon64 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wde
claration-after-statement -Wendif-labels -fno-strict-aliasing -I../../../../src/
include -D_GNU_SOURCE -c -o nbtinsert.o nbtinsert.c
nbtinsert.c: In function ‘_bt_insertonpg’:
nbtinsert.c:1065: warning: ‘state.best_delta’ may be used uninitialized in this
function
nbtinsert.c:1065: warning: ‘state.newitemonleft’ may be used uninitialized in th
is function
nbtinsert.c:1065: warning: ‘state.firstright’ may be used uninitialized in this
function

gcc -O3 -march=athlon64 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wde
claration-after-statement -Wendif-labels -fno-strict-aliasing -I../../../../src/
include -D_GNU_SOURCE -c -o costsize.o costsize.c
costsize.c: In function ‘cost_bitmap_or_node’:
costsize.c:707: warning: ‘subselec’ may be used uninitialized in this function
costsize.c:706: warning: ‘subCost’ may be used uninitialized in this function
costsize.c: In function ‘cost_bitmap_and_node’:
costsize.c:663: warning: ‘subselec’ may be used uninitialized in this function
costsize.c:662: warning: ‘subCost’ may be used uninitialized in this function
costsize.c: In function ‘cost_bitmap_heap_scan’:
costsize.c:514: warning: ‘indexSelectivity’ may be used uninitialized in this fu
nction
costsize.c:513: warning: ‘indexTotalCost’ may be used uninitialized in this func
tion


gcc -O3 -march=athlon64 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wde
claration-after-statement -Wendif-labels -fno-strict-aliasing -I../../../../src/
include -D_GNU_SOURCE -c -o numeric.o numeric.c
numeric.c: In function ‘numericvar_to_int4’:
numeric.c:1777: warning: ‘val’ may be used uninitialized in this function
numeric.c: In function ‘numeric_int2’:
numeric.c:1867: warning: ‘val’ may be used uninitialized in this function
numeric.c: In function ‘numeric_int8’:
numeric.c:1820: warning: ‘result’ may be used uninitialized in this function



gcc -O3 -march=athlon64 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wde
claration-after-statement -Wendif-labels -fno-strict-aliasing -I../../../../src/
include -D_GNU_SOURCE -c -o timestamp.o timestamp.c
timestamp.c: In function ‘timestamptz_zone’:
timestamp.c:4388: warning: ‘result’ may be used uninitialized in this function
timestamp.c: In function ‘timestamptz_timestamp’:
timestamp.c:4356: warning: ‘result’ may be used uninitialized in this function
timestamp.c: In function ‘timestamp2timestamptz’:
timestamp.c:4323: warning: ‘result’ may be used uninitialized in this function
timestamp.c: In function ‘timestamp_zone’:
timestamp.c:4215: warning: ‘result’ may be used uninitialized in this function
timestamp.c: In function ‘timestamptz_trunc’:
timestamp.c:3254: warning: ‘result’ may be used uninitialized in this function
timestamp.c: In function ‘SetEpochTimestamp’:
timestamp.c:1424: warning: ‘dt’ may be used uninitialized in this function
timestamp.c: In function ‘timestamptz_part’:
timestamp.c:1424: warning: ‘dt’ may be used uninitialized in this function
timestamp.c: In function ‘timestamp_part’:
timestamp.c:3799: warning: ‘timestamptz’ may be used uninitialized in this funct
ion
timestamp.c:1424: warning: ‘dt’ may be used uninitialized in this function
timestamp.c: In function ‘timestamp_in’:
timestamp.c:1424: warning: ‘dt’ may be used uninitialized in this function
timestamp.c: In function ‘timestamptz_in’:
timestamp.c:1424: warning: ‘dt’ may be used uninitialized in this function

gcc -O3 -march=athlon64 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wde
claration-after-statement -Wendif-labels -fno-strict-aliasing -Wno-error -pthrea
d -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -I../include -I../../.
../../src/interfaces/ecpg/include -I. -DMAJOR_VERSION=4 -DMINOR_VERSION=2 -DPATCH
LEVEL=1 -I../../../../src/include -D_GNU_SOURCE -c -o preproc.o preproc.c
In file included from preproc.y:6776:
pgc.c: In function ‘yylex’:
pgc.c:1570: warning: label ‘find_rule’ defined but not used

--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
.. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

mark@mark.mielke.cc writes:
> On Sun, Nov 05, 2006 at 09:11:07AM +0000, Simon Riggs wrote:
>> If that hit you then we're gonna get a few more people trip the same
>> way. Do you have any suggestions as to how to avoid that experience for
>> others?

> I believe the release notes are inadequate. I've read them three times
> before and it never stood out for me.

I put a note about this into "Migration to 8.2".

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

mark@mark.mielke.cc writes:
> On Sun, Nov 05, 2006 at 11:01:40AM -0500, Neil Conway wrote:
>> Presumably those are just the standard warnings we can't easiy
>> eliminate. If not, can you post them please?

> They all appear harmless.

The reason those "uninitialized variable" warnings got away from us is
that gcc doesn't emit them at -O2 or below, so most of us never saw 'em
before. I've cleaned them up.

The "find_rule" gripe is really a flex bug :-( ... not easy to avoid.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Fri, Nov 10, 2006 at 08:17:09PM -0500, Tom Lane wrote:
> mark@mark.mielke.cc writes:
> > On Sun, Nov 05, 2006 at 11:01:40AM -0500, Neil Conway wrote:
> >> Presumably those are just the standard warnings we can't easiy
> >> eliminate. If not, can you post them please?
> > They all appear harmless.
> The reason those "uninitialized variable" warnings got away from us is
> that gcc doesn't emit them at -O2 or below, so most of us never saw 'em
> before. I've cleaned them up.

Cool. Thanks. I like my compiles warnings free. :-)

> The "find_rule" gripe is really a flex bug :-( ... not easy to avoid.

*nod*

Cheers,
mark

--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
.. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq