Re: [PATCHES] htmlhelp generation
Am Montag, 22. November 2004 22:23 schrieb Tom Lane: Um ... what's an htmlhelp? It's the kind of format the Windows'ish programs use for their internal help browsers. It consists of regular HTML plus some index files. pgAdmin needs it, and maybe the Windows binary package would like it as well. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] htmlhelp generation
Am Montag, 22. November 2004 18:34 schrieb Andreas Pflug: The attached Makefile patch together with stylesheet-hh.xsl allows make htmlhelp. stylesheet-hh.xsl is derived from stylesheet.xsl, after some advise from PeterE. Installed. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] htmlhelp generation
Peter Eisentraut [EMAIL PROTECTED] writes: Am Montag, 22. November 2004 18:34 schrieb Andreas Pflug: The attached Makefile patch together with stylesheet-hh.xsl allows make htmlhelp. stylesheet-hh.xsl is derived from stylesheet.xsl, after some advise from PeterE. Installed. It would be nice if make clean would get rid of what this produces. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] htmlhelp generation
The attached Makefile patch together with stylesheet-hh.xsl allows make htmlhelp. stylesheet-hh.xsl is derived from stylesheet.xsl, after some advise from PeterE. Installed. From what I can tell, this XSL will download and import another XSL from docbook.sourceforge.net every time you run make on it. Perhaps a copy of this file should be included in cvs to make sure we can still build when sourceforge is down? //Magnus ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] htmlhelp generation
Magnus Hagander wrote: From what I can tell, this XSL will download and import another XSL from docbook.sourceforge.net every time you run make on it. Perhaps a copy of this file should be included in cvs to make sure we can still build when sourceforge is down? Using xsl:import here is not a good idea even if sourceforge isn't down - the imported file could change without our knowing, and thus the principle of least surprise would be violated, ISTM. cheers andrew ---(end of broadcast)--- TIP 3: 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 cleanly
Re: [PATCHES] htmlhelp generation
Magnus Hagander wrote: From what I can tell, this XSL will download and import another XSL from docbook.sourceforge.net every time you run make on it. Normally, you or your operating system should set up an XML catalog that maps that URI to a local copy. For example, my system has /etc/xml/catalog: ... delegateSystem systemIdStartString=http://docbook.sourceforge.net/release/xsl/; catalog=file:///etc/xml/docbook-xsl.xml/ and /etc/xml/docbook-xsl.xml: ... delegateSystem systemIdStartString=http://docbook.sourceforge.net/release/xsl/; catalog=file:///usr/share/xml/docbook/stylesheet/nwalsh/catalog.xml/ This is no different from the public identifier mapping in the SGML world, only that in the XML case it is possible, as a fallback, to fetch the data over the net. Whether you actually do that is between you and your XSLT processor. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] htmlhelp generation
From what I can tell, this XSL will download and import another XSL from docbook.sourceforge.net every time you run make on it. Normally, you or your operating system should set up an XML catalog that maps that URI to a local copy. For example, my system has /etc/xml/catalog: ... Hmm. Never seen that in any of the XSL systems I've used. There is certainly no such system in the XSLT processors that are included in Windows these days. But since those aren't used to build the docs, that's not a good reference point I guess. If there is a standard way to do it, there is less need to include anything in our cvs. IIRC, we don't include the docbook stylesheets either, right? Which brings up a different point - has anybody managed to set up a system to build the docs *on win32*? //Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] htmlhelp generation
Magnus Hagander wrote: Hmm. Never seen that in any of the XSL systems I've used. There is certainly no such system in the XSLT processors that are included in Windows these days. I don't know what's included in Windows, but all the usual ones you can download from the net support XML catalogs. Which brings up a different point - has anybody managed to set up a system to build the docs *on win32*? Cygwin includes openjade, and xsltproc runs natively, so there shouldn't be much of a problem. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Translation updates for 8.0: initdb-ro, pg_dump-ro, psql-ro
Alin Vaida wrote: Please update these files. Done. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[PATCHES] Romanian translation for 8.0: new files (pg_config-ro, pg_ctl-ro, pg_resetxlog-ro)
Please update the corresponding nls.mk files. Thank you, Alin Vaida pg_resetxlog-ro.po Description: application/gettext pg_config-ro.po Description: application/gettext pg_ctl-ro.po Description: application/gettext ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[PATCHES] SQL:2003 keyword additions
as per SQL:2003 Annex E pp.1173-1175 Incompatibilities with SQL:1999,
specifically point 17, pp.1174-1175:
A number of additional reserved words have been added to the
language.
Enjoy.
--
Best Regards, Simon Riggs
Index: keywords.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/parser/keywords.c,v
retrieving revision 1.153
diff -d -c -r1.153 keywords.c
*** keywords.c 29 Aug 2004 04:12:40 - 1.153
--- keywords.c 23 Nov 2004 22:46:48 -
***
*** 50,55
--- 50,56
{assertion, ASSERTION},
{assignment, ASSIGNMENT},
{at, AT},
+ {atomic, ATOMIC},
{authorization, AUTHORIZATION},
{backward, BACKWARD},
{before, BEFORE},
***
*** 77,86
--- 78,89
{cluster, CLUSTER},
{coalesce, COALESCE},
{collate, COLLATE},
+ {collect, COLLECT},
{column, COLUMN},
{comment, COMMENT},
{commit, COMMIT},
{committed, COMMITTED},
+ {condition, CONDITION},
{constraint, CONSTRAINT},
{constraints, CONSTRAINTS},
{conversion, CONVERSION_P},
***
*** 119,124
--- 122,128
{drop, DROP},
{each, EACH},
+ {element, ELEMENT},
{else, ELSE},
{encoding, ENCODING},
{encrypted, ENCRYPTED},
{end, END_P},
***
*** 143,148
--- 147,153
{from, FROM},
{full, FULL},
{function, FUNCTION},
+ {fusion, FUSION},
{global, GLOBAL},
{grant, GRANT},
{group, GROUP_P},
***
*** 169,174
--- 174,180
{int, INT_P},
{integer, INTEGER},
{intersect, INTERSECT},
+ {intersection, INTERSECTION},
{interval, INTERVAL},
{into, INTO},
{invoker, INVOKER},
***
*** 195,205
--- 201,214
{lock, LOCK_P},
{match, MATCH},
{maxvalue, MAXVALUE},
+ {member, MEMBER},
+ {merge, MERGE},
{minute, MINUTE_P},
{minvalue, MINVALUE},
{mode, MODE},
{month, MONTH_P},
{move, MOVE},
+ {multiset, MULTISET},
{names, NAMES},
{national, NATIONAL},
{natural, NATURAL},
***
*** 210,215
--- 219,225
{nocreatedb, NOCREATEDB},
{nocreateuser, NOCREATEUSER},
{none, NONE},
+ {normalize, NORMALIZE},
{not, NOT},
{nothing, NOTHING},
{notify, NOTIFY},
***
*** 294,302
--- 304,314
{stdout, STDOUT},
{storage, STORAGE},
{strict, STRICT_P},
+ {submultiset, SUBMULTISET},
{substring, SUBSTRING},
{sysid, SYSID},
{table, TABLE},
+ {tablesample, TABLESAMPLE},
{tablespace, TABLESPACE},
{temp, TEMP},
{template, TEMPLATE},
***
*** 315,320
--- 327,333
{truncate, TRUNCATE},
{trusted, TRUSTED},
{type, TYPE_P},
+ {uescape, UESCAPE},
{uncommitted, UNCOMMITTED},
{unencrypted, UNENCRYPTED},
{union, UNION},
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Romanian translation for 8.0: new files (pg_config-ro, pg_ctl-ro, pg_resetxlog-ro)
Alin Vaida wrote: Please update the corresponding nls.mk files. Done. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] SQL:2003 keyword additions
Simon Riggs wrote: as per SQL:2003 Annex E pp.1173-1175 Incompatibilities with SQL:1999, specifically point 17, pp.1174-1175: A number of additional reserved words have been added to the language. I think you are confusing keywords.c with the SQL standard. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] SQL Conformance introductory section
Simon Riggs wrote: I've re-written the start of the SQL Conformance section to update things for the SQL2003 standard. This has got to be a mistake: Overall, PostgreSQL Global Development Group (acronymPGDG/acronym) supports open standards, particularly the SQL standard. By what norm is the SQL standard an open standard? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: 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 cleanly
Re: [PATCHES] SQL:2003 keyword additions
Simon Riggs [EMAIL PROTECTED] writes: as per SQL:2003 Annex E pp.1173-1175 Incompatibilities with SQL:1999, specifically point 17, pp.1174-1175: A number of additional reserved words have been added to the language. We are not going to reserve words simply because they are reserved in the standard. We go out of our way to make words as little reserved as possible; words that we are not even using in the grammar don't have to be reserved at all. For future reference, the patch as proposed is broken anyway because it doesn't add the keywords to the appropriate list in gram.y. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] SQL:2003 keyword additions
On Tue, 2004-11-23 at 23:22, Tom Lane wrote: For future reference, the patch as proposed is broken anyway because it doesn't add the keywords to the appropriate list in gram.y. OK, thanks. -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] SQL:2003 keyword additions
On Tue, 2004-11-23 at 23:08, Peter Eisentraut wrote: Simon Riggs wrote: as per SQL:2003 Annex E pp.1173-1175 Incompatibilities with SQL:1999, specifically point 17, pp.1174-1175: A number of additional reserved words have been added to the language. I think you are confusing keywords.c with the SQL standard. Hmmm... the difference was clear to me, since I edited one, but not the other. ;) If you are saying we should not support the SQL standard with regard to the new reserved words added in SQL:2003, I would understand, but not agree. With you lies the power to apply, all some or none of the patch, as you choose. It was tedious enough to write the patch... -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] SQL Conformance introductory section
On Tue, 2004-11-23 at 23:15, Peter Eisentraut wrote: Simon Riggs wrote: I've re-written the start of the SQL Conformance section to update things for the SQL2003 standard. This has got to be a mistake: Overall, PostgreSQL Global Development Group (acronymPGDG/acronym) supports open standards, particularly the SQL standard. By what norm is the SQL standard an open standard? No mistake, but I note your disagreement. I'm not thrilled by the way the latest SQL standard was put together, but it draws much respect from others - so I take note. A statement from the core team on standards support would, IMHO, be a useful addition to that chapter. Troels and I are re-writing that whole chapter together now and will submit when it is coherent and accurate. Troels has done much more work on this than I. It's probably worth waiting now and reviewing the completed whole. My efforts are the result of a commitment to update the docs to match the latest standard, not because I love the exactness of it. With respect, the meaning of the word open isn't something I would get involved with. -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] rtree: improve performance, tuple killing
This patch makes some improvements to the rtree index implementation:
(1) Keep a pin on the scan's current buffer and mark buffer. This avoids
the need to do a ReadBuffer() for each tuple produced by the scan.
(2) Convert a ReleaseBuffer() ; ReadBuffer() pair into
ReleaseAndReadBuffer(). Surely not a huge win, but it saves a lock
acquire/release...
(3) Remove a bunch of duplicated code in rtget.c; make rtnext() handle
both the initial result and subsequent result cases.
(4) Add support for index tuple killing
(5) Remove rtscancache(): it is dead code, for the same reason that
gistscancache() is dead code (an index scan ought not be invoked with
NoMovementScanDirection).
The end result is about a 10% improvement in index scan performance,
according to contrib/rtree_gist/bench.
These changes (with the exception of #2) are analogous to changes I've
already made for GiST (it's clear that GiST was started as a fork of
rtree). I'm not hugely interested in further improvements to rtree; I
just did this stuff because it is low-hanging fruit and I've already
made the same changes for GiST.
-Neil
#
# patch src/backend/access/rtree/rtget.c
# from [3db9a1c0391d9e319ac8455167f23215e00bf832]
#to [ebfe121a3bcd3e2a15da91e14a84b69c87afac67]
#
# patch src/backend/access/rtree/rtree.c
# from [274583f574bc483a709b46912a567c58c6abb98c]
#to [8df26216af5a60db10afd38e3f1dc5c6355ec79c]
#
# patch src/backend/access/rtree/rtscan.c
# from [9ace8f57b28397296b386955fdf3b7b712178a9a]
#to [92b177352fd28ffab208ac9abf502cb4c81d2740]
#
# patch src/include/access/rtree.h
# from [d3b048ba826b36bc766de324779c0b5bbb143b42]
#to [e4947131a99641d8f43c4b7b770485c8c1043094]
#
--- src/backend/access/rtree/rtget.c
+++ src/backend/access/rtree/rtget.c
@@ -19,10 +19,8 @@
#include access/relscan.h
#include access/rtree.h
-static OffsetNumber findnext(IndexScanDesc s, Page p, OffsetNumber n,
+static OffsetNumber findnext(IndexScanDesc s, OffsetNumber n,
ScanDirection dir);
-static bool rtscancache(IndexScanDesc s, ScanDirection dir);
-static bool rtfirst(IndexScanDesc s, ScanDirection dir);
static bool rtnext(IndexScanDesc s, ScanDirection dir);
@@ -31,138 +29,106 @@
{
IndexScanDesc s = (IndexScanDesc) PG_GETARG_POINTER(0);
ScanDirection dir = (ScanDirection) PG_GETARG_INT32(1);
- bool res;
-
- /* if we have it cached in the scan desc, just return the value */
- if (rtscancache(s, dir))
- PG_RETURN_BOOL(true);
-
- /* not cached, so we'll have to do some work */
- if (ItemPointerIsValid((s-currentItemData)))
- res = rtnext(s, dir);
- else
- res = rtfirst(s, dir);
- PG_RETURN_BOOL(res);
-}
-
-static bool
-rtfirst(IndexScanDesc s, ScanDirection dir)
-{
- Buffer b;
- Page p;
- OffsetNumber n;
- OffsetNumber maxoff;
- RTreePageOpaque po;
+ Page page;
+ OffsetNumber offnum;
RTreeScanOpaque so;
- RTSTACK*stk;
- BlockNumber blk;
- IndexTuple it;
- b = ReadBuffer(s-indexRelation, P_ROOT);
- p = BufferGetPage(b);
- po = (RTreePageOpaque) PageGetSpecialPointer(p);
so = (RTreeScanOpaque) s-opaque;
- for (;;)
+ /*
+ * If we've already produced a tuple and the executor has informed
+ * us that it should be marked killed, do so know.
+ */
+ if (s-kill_prior_tuple ItemPointerIsValid((s-currentItemData)))
{
- maxoff = PageGetMaxOffsetNumber(p);
- if (ScanDirectionIsBackward(dir))
- n = findnext(s, p, maxoff, dir);
- else
- n = findnext(s, p, FirstOffsetNumber, dir);
+ offnum = ItemPointerGetOffsetNumber((s-currentItemData));
+ page = BufferGetPage(so-curbuf);
+ PageGetItemId(page, offnum)-lp_flags |= LP_DELETE;
+ SetBufferCommitInfoNeedsSave(so-curbuf);
+ }
- while (n FirstOffsetNumber || n maxoff)
- {
- ReleaseBuffer(b);
- if (so-s_stack == NULL)
-return false;
+ /*
+ * Get the next tuple that matches the search key; if asked to
+ * skip killed tuples, find the first non-killed tuple that
+ * matches. Return as soon as we've run out of matches or we've
+ * found an acceptable match.
+ */
+ for (;;)
+ {
+ bool res = rtnext(s, dir);
- stk = so-s_stack;
- b = ReadBuffer(s-indexRelation, stk-rts_blk);
- p = BufferGetPage(b);
- po = (RTreePageOpaque) PageGetSpecialPointer(p);
- maxoff = PageGetMaxOffsetNumber(p);
-
- if (ScanDirectionIsBackward(dir))
-n = OffsetNumberPrev(stk-rts_child);
- else
-n = OffsetNumberNext(stk-rts_child);
- so-s_stack = stk-rts_parent;
- pfree(stk);
-
- n = findnext(s, p, n, dir);
- }
- if (po-flags F_LEAF)
+ if (res == true s-ignore_killed_tuples)
{
- ItemPointerSet((s-currentItemData), BufferGetBlockNumber(b), n);
-
- it = (IndexTuple) PageGetItem(p, PageGetItemId(p, n));
-
- s-xs_ctup.t_self = it-t_tid;
-
- ReleaseBuffer(b);
- return true;
+ offnum = ItemPointerGetOffsetNumber((s-currentItemData));
+ page = BufferGetPage(so-curbuf);
+ if (ItemIdDeleted(PageGetItemId(page, offnum)))
+continue;
}
- else
- {
- stk = (RTSTACK *) palloc(sizeof(RTSTACK));
- stk-rts_child = n;
-
[PATCHES] minor bufmgr cleanup
This patch makes a trivial improvement to IncrBufferRefCount(): rather
than asserting that BufferIsValid() and then manually asserting its pin
count is 0, we can just assert BufferIsPinned().
I'll apply to HEAD before end of day, barring any objections.
-Neil
--- src/backend/storage/buffer/bufmgr.c
+++ src/backend/storage/buffer/bufmgr.c
@@ -1549,25 +1549,18 @@
* at least once.
*
* This function cannot be used on a buffer we do not have pinned,
- * because it doesn't change the shared buffer state. Therefore the
- * Assert checks are for refcount 0. Someone got this wrong once...
+ * because it doesn't change the shared buffer state.
*/
void
IncrBufferRefCount(Buffer buffer)
{
- Assert(BufferIsValid(buffer));
+ Assert(BufferIsPinned(buffer));
ResourceOwnerEnlargeBuffers(CurrentResourceOwner);
ResourceOwnerRememberBuffer(CurrentResourceOwner, buffer);
if (BufferIsLocal(buffer))
- {
- Assert(LocalRefCount[-buffer - 1] 0);
LocalRefCount[-buffer - 1]++;
- }
else
- {
- Assert(PrivateRefCount[buffer - 1] 0);
PrivateRefCount[buffer - 1]++;
- }
}
#ifdef NOT_USED
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] htmlhelp generation
Um ... what's an htmlhelp? It's the kind of format the Windows'ish programs use for their internal help browsers. It consists of regular HTML plus some index files. pgAdmin needs it, and maybe the Windows binary package would like it as well. I've trivially generated them from docbook xml using the htmlhelp.xsl stylesheet that comes with docbook and the free html help compiler from MS. Chris ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] minor bufmgr cleanup
On Wed, 2004-11-24 at 11:18 +1100, Neil Conway wrote: This patch makes a trivial improvement to IncrBufferRefCount(): rather than asserting that BufferIsValid() and then manually asserting its pin count is 0, we can just assert BufferIsPinned(). Applied. -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
