Re: [PATCHES] Load distributed checkpoint V3
From: "Greg Smith" <[EMAIL PROTECTED]> > If you compare how Oracle handles their writes and checkpoints to the > Postgres code, it's obvious they have a different architecture that > enables them to support sync writing usefully. I'd recommend the Database > Writer Process section of > http://www.lc.leidenuniv.nl/awcourse/oracle/server.920/a96524/c09procs.htm > as an introduction for those not familiar with that; it's interesting > reading for anyone tinking with background writer code. Hmm... what makes you think that sync writes is useful for Oracle and not for PostgreSQL? The process architecture is similar; bgwriter performs most of writes in PostgreSQL, while DBWn performs all writes in Oracle. The difference is that Oracle can assure crash recovery time by writing dirby buffers periodically in the order of their LSN. > It would be great to compare performance of the current PostgreSQL code > with a fancy multiple background writer version using the latest sync > methods or AIO; there have actually been multiple updates to improve > O_SYNC writes within Linux during the 2.6 kernel series that make this > more practical than ever on that platform. But as you've already seen, > the performance hurdle to overcome is significant, and it would have to be > optional as a result. When you add all this up--have to keep the current > non-sync writes around as well, need to redesign the whole background > writer/checkpoint approach around the idea of sync writes, and the > OS-specific parts that would come from things like AIO--it gets real > messy. Good luck drumming up support for all that when the initial > benchmarks suggest it's going to be a big step back. I agree with you in that write method has to be optional until there's enough data from the field that help determine which is better. ... It's a pity not to utilize async I/O and Josh-san's offer. I hope it will be used some day. I think OS developers have evolved async I/O for databases. ---(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
Re: [PATCHES] Packed Varlena Update (v21)
"Tom Lane" <[EMAIL PROTECTED]> writes: > I wrote: >> stark <[EMAIL PROTECTED]> writes: >>> [ packed varlena patch ] > >> Applied with revisions. > > Forgot to mention: one of the revisions was to not add the "sizes.sql" > test, because the output was platform-dependent and is likely to get > more so if any ability to change the toast thresholds gets put in. > Can we improve that test to not expose any platform-dependent numbers? I had imagined that we would have two versions of output files. Other than 32-bit versus 64-bit what other platform-dependent variations enter into it? I'll look at it again on a 64-bit machine, but probably not for another week. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(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
Re: [PATCHES] Load distributed checkpoint V3
On Fri, 2007-04-06 at 02:53 -0400, Greg Smith wrote: > If you compare how Oracle handles their writes and checkpoints to the > Postgres code, it's obvious they have a different architecture that > enables them to support sync writing usefully. I'd recommend the > Database > Writer Process section of > http://www.lc.leidenuniv.nl/awcourse/oracle/server.920/a96524/c09procs.htm > as an introduction for those not familiar with that; it's interesting > reading for anyone tinking with background writer code. Oracle does have a different checkpointing technique and we know it is patented, so we need to go carefully there, especially when directly referencing documentation. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] Fix for large file support
Current version of postgres support only 1GB chunks. This limit is
defined in the pg_config_manual.h header file. However this setting
allows to have maximal 2GB chunks. Main problem is that md storage
manager and buffile use "long" data type (32bits) for offset instead
"off_t" defined in .
off_t is 32bits long on 32bits OS and 64bits long on 64bits OS or when
application is compiled with large file support.
Attached patch allow to setup bigger chunks than 4GB on OS with large
file support.
I tested it on 7GB table and it works.
Please, look on it and let me know your comments or if I miss something.
TODO/questions:
1) clean/update comments about limitation
2) Is there some doc for update?
3) I would like to add some check compare sizeof(off_t) and chunk size
setting and protect postgres with missconfigured chunk size. Is mdinit()
good place for this check?
4) I'm going to take bigger machine for test with really big table.
with regards Zdenek
Index: src/backend/storage/file/buffile.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/storage/file/buffile.c,v
retrieving revision 1.25
diff -c -r1.25 buffile.c
*** src/backend/storage/file/buffile.c 5 Jan 2007 22:19:37 - 1.25
--- src/backend/storage/file/buffile.c 6 Apr 2007 12:08:47 -
***
*** 42,48
* Note we adhere to this limit whether or not LET_OS_MANAGE_FILESIZE
* is defined, although md.c ignores it when that symbol is defined.
*/
! #define MAX_PHYSICAL_FILESIZE (RELSEG_SIZE * BLCKSZ)
/*
* This data structure represents a buffered file that consists of one or
--- 42,48
* Note we adhere to this limit whether or not LET_OS_MANAGE_FILESIZE
* is defined, although md.c ignores it when that symbol is defined.
*/
! #define MAX_PHYSICAL_FILESIZE ((off_t)RELSEG_SIZE * BLCKSZ)
/*
* This data structure represents a buffered file that consists of one or
***
*** 54,60
int numFiles; /* number of physical files in set */
/* all files except the last have length exactly MAX_PHYSICAL_FILESIZE */
File *files; /* palloc'd array with numFiles entries */
! long *offsets; /* palloc'd array with numFiles entries */
/*
* offsets[i] is the current seek position of files[i]. We use this to
--- 54,60
int numFiles; /* number of physical files in set */
/* all files except the last have length exactly MAX_PHYSICAL_FILESIZE */
File *files; /* palloc'd array with numFiles entries */
! off_t *offsets; /* palloc'd array with numFiles entries */
/*
* offsets[i] is the current seek position of files[i]. We use this to
***
*** 70,76
* Position as seen by user of BufFile is (curFile, curOffset + pos).
*/
int curFile; /* file index (0..n) part of current pos */
! int curOffset; /* offset part of current pos */
int pos; /* next read/write position in buffer */
int nbytes; /* total # of valid bytes in buffer */
char buffer[BLCKSZ];
--- 70,76
* Position as seen by user of BufFile is (curFile, curOffset + pos).
*/
int curFile; /* file index (0..n) part of current pos */
! off_t curOffset; /* offset part of current pos */
int pos; /* next read/write position in buffer */
int nbytes; /* total # of valid bytes in buffer */
char buffer[BLCKSZ];
***
*** 95,101
file->numFiles = 1;
file->files = (File *) palloc(sizeof(File));
file->files[0] = firstfile;
! file->offsets = (long *) palloc(sizeof(long));
file->offsets[0] = 0L;
file->isTemp = false;
file->dirty = false;
--- 95,101
file->numFiles = 1;
file->files = (File *) palloc(sizeof(File));
file->files[0] = firstfile;
! file->offsets = (off_t *) palloc(sizeof(off_t));
file->offsets[0] = 0L;
file->isTemp = false;
file->dirty = false;
***
*** 121,128
file->files = (File *) repalloc(file->files,
(file->numFiles + 1) * sizeof(File));
! file->offsets = (long *) repalloc(file->offsets,
! (file->numFiles + 1) * sizeof(long));
file->files[file->numFiles] = pfile;
file->offsets[file->numFiles] = 0L;
file->numFiles++;
--- 121,128
file->files = (File *) repalloc(file->files,
(file->numFiles + 1) * sizeof(File));
! file->offsets = (off_t *) repalloc(file->offsets,
! (file->numFiles + 1) * sizeof(off_t));
file->files[file->numFiles] = pfile;
file->offsets[file->numFiles] = 0L;
file->numFiles++;
***
*** 273,281
bytestowrite = file->nbytes - wpos;
if (file->isTemp)
{
! long availbytes = MAX_PHYSICAL_FILESIZE - file->curOffset;
! if ((long) bytestowrite > availbytes)
bytestowrite = (int) availbytes;
}
--- 273,281
bytestowrite = file->nbytes - wpos;
if (file->isTemp)
{
! off_t availbytes = MAX_PHYSICAL_
Re: [PATCHES] Optimized pgbench for 8.3
Patch committed. Thanks. -- Tatsuo Ishii SRA OSS, Inc. Japan > The attached is a patch to optimize contrib/pgbench using new 8.3 features. > > - Use DROP IF EXISTS to suppress errors for initial loadings. > - Use a combination of TRUNCATE and COPY to reduce WAL on creating > the accounts table. > > Also, there are some cosmetic changes. > > - Change the output of -v option from "starting full vacuum..." > to "starting vacuum accounts..." in reflection of the fact. > - Shape duplicated error checks into executeStatement(). > > > There is a big performance win in "COPY with no WAL" feature. > Thanks for the efforts! > > Regards, > --- > ITAGAKI Takahiro > NTT Open Source Software Center ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Fix for large file support
Zdenek Kotala wrote: Current version of postgres support only 1GB chunks. This limit is defined in the pg_config_manual.h header file. However this setting allows to have maximal 2GB chunks. Main problem is that md storage manager and buffile use "long" data type (32bits) for offset instead "off_t" defined in . off_t is 32bits long on 32bits OS and 64bits long on 64bits OS or when application is compiled with large file support. Attached patch allow to setup bigger chunks than 4GB on OS with large file support. I tested it on 7GB table and it works. What does it actually buy us, though? Does it mean the maximum field size will grow beyond 1Gb? Or give better performance? cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Fix for large file support
Andrew Dunstan wrote: Does it mean the maximum field size will grow beyond 1Gb? No. Because it is limited by varlena size. See http://www.postgresql.org/docs/8.2/interactive/storage-toast.html Or give better performance? Yes. List of chunks is stored as linked list and for some operation (e.g. expand) are all chunks opened and their size is checked. On big tables it takes some time. For example if you have 1TB big table and you want to add new block you must go and open all 1024 files. By the way ./configure script performs check for __LARGE_FILE_ support, but it looks that it is nowhere used. There could be small time penalty in 64bit arithmetics. However it happens only if large file support is enabled on 32bit OS. Zdenek ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Packed Varlena Update (v21)
Gregory Stark <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> writes: >> Forgot to mention: one of the revisions was to not add the "sizes.sql" >> test, because the output was platform-dependent and is likely to get >> more so if any ability to change the toast thresholds gets put in. >> Can we improve that test to not expose any platform-dependent numbers? > I had imagined that we would have two versions of output files. Other than > 32-bit versus 64-bit what other platform-dependent variations enter into it? If there'd be only two then I'd be all right with it, but I'm worried that making TOAST thresholds configurable would result in lots more possible outputs than that. BTW, another area that should be kept on the TODO list is to see whether it makes sense to support 1-byte-header format for array elements. I looked at that briefly while reviewing the patch but decided it was a large additional chunk of work and not on the critical path. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Fix for large file support
Zdenek Kotala <[EMAIL PROTECTED]> writes: > Andrew Dunstan wrote: >> Or give better performance? > Yes. List of chunks is stored as linked list and for some operation > (e.g. expand) are all chunks opened and their size is checked. On big > tables it takes some time. For example if you have 1TB big table and you > want to add new block you must go and open all 1024 files. Indeed, but that would be far more effectively addressed by fixing the *other* code path that doesn't segment at all (the LET_OS_MANAGE_FILESIZE option, which is most likely broken these days for lack of testing). I don't see the point of a halfway measure like increasing RELSEG_SIZE. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Fix for large file support
Tom Lane wrote: Zdenek Kotala <[EMAIL PROTECTED]> writes: Andrew Dunstan wrote: Indeed, but that would be far more effectively addressed by fixing the *other* code path that doesn't segment at all (the LET_OS_MANAGE_FILESIZE option, which is most likely broken these days for lack of testing). I don't see the point of a halfway measure like increasing RELSEG_SIZE. LET_OS_MANAGE_FILESIZE is good way. I think one problem of this option I fixed. It is size of offset. I went thru the code and did not see any other problem there. However, how you mentioned it need more testing. I going to take server with large disk array and I will test it. I would like to add --enable-largefile switch to configure file to enable access to wide group of users. What you think about it? Zdenek ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Load distributed checkpoint V3
On Fri, 6 Apr 2007, Takayuki Tsunakawa wrote: Hmm... what makes you think that sync writes is useful for Oracle and not for PostgreSQL? They do more to push checkpoint-time work in advance, batch writes up more efficiently, and never let clients do the writing. All of which make for a different type of checkpoint. Like Simon points out, even if it were conceivable to mimic their design it might not even be legally feasible. The point I was trying to make is this: you've been saying that Oracle's writing technology has better performance in this area, which is probably true, and suggesting the cause of that was their using O_SYNC writes. I wanted to believe that and even tested out a prototype. The reality here appears to be that their checkpoints go smoother *despite* using the slower sync writes because they're built their design around the limitations of that write method. I suspect it would take a similar scale of redesign to move Postgres in that direction; the issues you identified (the same ones I ran into) are not so easy to resolve. You're certainly not going to move anybody in that direction by throwing a random comment into a discussion on the patches list about a feature useful *right now* in this area. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] index support is NULL
Teodor Sigaev <[EMAIL PROTECTED]> writes: > http://www.sigaev.ru/misc/indexnulls-0.8.gz Applied with revisions (except I didn't touch the gist code, figuring you probably understand that better than me). regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] Fix misleading references to columns in GRANT/REVOKE summaries
Folks,
Per a question Alexey Parshin asked in the IRC channel, I'm attaching
a patch to the GRANT and REVOKE syntax summaries which replaces the
misleading word "column" with "parameter." "Column" is misleading
because it could be read to imply a column-level GRANT/REVOKE, which
we don't have yet.
Cheers,
D
--
David Fetter <[EMAIL PROTECTED]> http://fetter.org/
phone: +1 415 235 3778AIM: dfetter666
Skype: davidfetter
Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate
Index: doc/src/sgml/ref/grant.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/grant.sgml,v
retrieving revision 1.64
diff -c -r1.64 grant.sgml
*** doc/src/sgml/ref/grant.sgml 1 Feb 2007 00:28:19 - 1.64
--- doc/src/sgml/ref/grant.sgml 6 Apr 2007 23:39:20 -
***
*** 525,531
GRANT privileges
! ON table [ ( column [, ...] ) ] [, ...]
TO { PUBLIC | username [,
...] } [ WITH GRANT OPTION ]
--- 525,532
GRANT privileges
! ON table [ (
! parameter [, ...] ) ] [, ...]
TO { PUBLIC | username [,
...] } [ WITH GRANT OPTION ]
Index: doc/src/sgml/ref/revoke.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/revoke.sgml,v
retrieving revision 1.42
diff -c -r1.42 revoke.sgml
*** doc/src/sgml/ref/revoke.sgml31 Jan 2007 23:26:04 - 1.42
--- doc/src/sgml/ref/revoke.sgml6 Apr 2007 23:39:20 -
***
*** 235,241
REVOKE [ GRANT OPTION FOR ] privileges
! ON object [ ( column [, ...] ) ]
FROM { PUBLIC | username [,
...] }
{ RESTRICT | CASCADE }
--- 235,242
REVOKE [ GRANT OPTION FOR ] privileges
! ON object [ (
! parameter [, ...] ) ]
FROM { PUBLIC | username [,
...] }
{ RESTRICT | CASCADE }
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [PATCHES] [DOCS] Fix misleading references to columns in GRANT/REVOKE summaries
David Fetter <[EMAIL PROTECTED]> writes: > Per a question Alexey Parshin asked in the IRC channel, I'm attaching > a patch to the GRANT and REVOKE syntax summaries which replaces the > misleading word "column" with "parameter." "Column" is misleading > because it could be read to imply a column-level GRANT/REVOKE, which > we don't have yet. Apparently it's so misleading that you didn't understand it either. The entire *point* of that paragraph is that we don't have the feature. This proposed change is surely not an improvement... regards, tom lane ---(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
Re: [PATCHES] [DOCS] Fix misleading references to columns in GRANT/REVOKE summaries
Tom Lane wrote: David Fetter <[EMAIL PROTECTED]> writes: Per a question Alexey Parshin asked in the IRC channel, I'm attaching a patch to the GRANT and REVOKE syntax summaries which replaces the misleading word "column" with "parameter." "Column" is misleading because it could be read to imply a column-level GRANT/REVOKE, which we don't have yet. Apparently it's so misleading that you didn't understand it either. The entire *point* of that paragraph is that we don't have the feature. This proposed change is surely not an improvement... Maybe removing the entire example would be more helpful. I don't find it clear to have a command outline in a compatibility block. regards, tom lane ---(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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] [Fwd: Index Advisor]
"Gurjeet Singh" <[EMAIL PROTECTED]> writes: > Please find attached the latest version of the patch. It applies cleanly on > REL8_2_STABLE. The interface to the planner in this seems rather brute-force. To run a plan involving a hypothetical index, you have to make a bunch of catalog entries, run the planner, and then roll back the transaction to get rid of the entries. Slow, ugly, and you still need another kluge to keep the planner from believing the index has zero size. It strikes me that there is a better way to do it, because 99% of the planner does not look at the system catalog entries --- all it cares about is the IndexOptInfo structs set up by plancat.c. So there's not really any need to make catalog entries at all AFAICS. Rather, the best thing would be a plugin hook at the end of get_relation_info() that would have a chance to editorialize on the constructed IndexOptInfo list (and maybe other properties of the RelOptInfo too). You could remove existing index entries or insert new ones. I'm dissatisfied with the hard-wired hook into planner() also. That doesn't provide any extensibility nor allow the index adviser to be implemented as a loadable plugin. I'm inclined to think it's in the wrong place anyway; you've got thrashing around there to avoid recursion but it's very fragile. Having to dump the results into the postmaster log isn't a nice user API either. Perhaps what would be better is a hook in EXPLAIN to call a plugin that can add more lines to EXPLAIN's output, and is passed the original query and plan so that it can re-call the planner with hypothetical indexes prepared for insertion by the other hook. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [DOCS] Fix misleading references to columns in GRANT/REVOKE summaries
Russell Smith <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> The entire *point* of that paragraph is that we don't have the >> feature. This proposed change is surely not an improvement... >> > Maybe removing the entire example would be more helpful. I don't find > it clear to have a command outline in a compatibility block. True, there doesn't seem to be any point in providing a full syntax summary rather than just saying "the SQL spec says you can grant privileges on columns but we don't support that yet". regards, tom lane ---(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
Re: [PATCHES] Optimized pgbench for 8.3
FYI, patch applied by Tatsuo. Thanks. --- ITAGAKI Takahiro wrote: > The attached is a patch to optimize contrib/pgbench using new 8.3 features. > > - Use DROP IF EXISTS to suppress errors for initial loadings. > - Use a combination of TRUNCATE and COPY to reduce WAL on creating > the accounts table. > > Also, there are some cosmetic changes. > > - Change the output of -v option from "starting full vacuum..." > to "starting vacuum accounts..." in reflection of the fact. > - Shape duplicated error checks into executeStatement(). > > > There is a big performance win in "COPY with no WAL" feature. > Thanks for the efforts! > > Regards, > --- > ITAGAKI Takahiro > NTT Open Source Software Center [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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 cleanly
Re: [PATCHES] pgbench transaction timestamps
FYI, patch applied by Tatsuo. Thanks. --- Greg Smith wrote: > This patch changes the way pgbench outputs its latency log files so that > every transaction gets a timestamp and notes which transaction type was > executed. It's a one-line change that just dumps some additional > information that was already sitting in that area of code. I also made a > couple of documentation corrections and clarifications on some of the more > confusing features of pgbench. > > It's straightforward to parse log files in this format to analyze what > happened during the test at a higher level than was possible with the > original format. You can find some rough sample code to convert this > latency format into CVS files and then into graphs at > http://www.westnet.com/~gsmith/content/postgresql/pgbench.htm which I'll > be expanding on once I get all my little patches sent in here. > > If you recall the earlier version of this patch I submitted, it added a > cleanup feature that did a vacuum and checkpoint after the test was > finished and reported two TPS results. The idea was to quantify how much > of a hit the eventual table maintenance required to clean up after the > test would take. While those things do influence results and cause some > of the run-to-run variation in TPS (checkpoints are particularly visible > in the graphs), after further testing I concluded running a VACUUM VERBOSE > and CHECKPOINT in a script afterwards and analyzing the results was more > useful than integrating something into pgbench itself. > > -- > * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD Content-Description: [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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
[PATCHES] Correct the spelling of SYMMETRIC
Correct the spelling of SYMMETRIC. -- Michael Fuhr Index: doc/src/sgml/func.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/func.sgml,v retrieving revision 1.375 diff -c -r1.375 func.sgml *** doc/src/sgml/func.sgml 5 Apr 2007 01:46:27 - 1.375 --- doc/src/sgml/func.sgml 7 Apr 2007 03:19:49 - *** *** 280,286 the CPU cycles required to rewrite the first one into the second one internally. ! BETWEEN SYMETRIC BETWEEN SYMMETRIC is the same as BETWEEN except there is no requirement that the argument to the left of AND be less than --- 280,286 the CPU cycles required to rewrite the first one into the second one internally. ! BETWEEN SYMMETRIC BETWEEN SYMMETRIC is the same as BETWEEN except there is no requirement that the argument to the left of AND be less than ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Correct the spelling of SYMMETRIC
Patch applied. Thanks. Your documentation changes can be viewed in five minutes using links on the developer's page, http://www.postgresql.org/developer/testing. --- Michael Fuhr wrote: > Correct the spelling of SYMMETRIC. > > -- > Michael Fuhr [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] HOT Patch - Ready for review
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Pavan Deolasee wrote: > Please find the attached HOT patch, which I think is now ready for > review. > > The only known issue left to-be-done is making the index available > in the read-committed transaction which created it. Right now the index > is made available to the transaction unless one or more rows were > UPDATEd in the same transactions before creating the index OR there were > RECENTLY_DEAD tuples that we did not index while building the index. > Both of these cases do not seem very common to me.The patch can easily > be tweaked to make the index available even in these cases, but I left it > because Tom has raised concerns about transaction using the new index > with some old snapshot. I haven't been able to create such a scenario > so thought would best leave it until someone picks it up for review and > take it up at that time. > > One of the regression test fails, but thats just a side-effect of how CIC > works now. I didn't change the expected output just yet because that might > have covered this side-effect. I plan to spend some time on performance > testing and would post those results soon. > > I would appreciate if others also give it a shot and see if it gives any > performance jump in their respective setups. I think the best would > come out in IO bound testing. > > Thanks, > Pavan > > -- > > EnterpriseDB http://www.enterprisedb.com [ Attachment, skipping... ] > > ---(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 cleanly -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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 cleanly
Re: [PATCHES] [DOCS] Fix misleading references to columns in GRANT/REVOKE summaries
Tom Lane wrote:
> Russell Smith <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> The entire *point* of that paragraph is that we don't have the
> >> feature. This proposed change is surely not an improvement...
> >>
> > Maybe removing the entire example would be more helpful. I don't find
> > it clear to have a command outline in a compatibility block.
>
> True, there doesn't seem to be any point in providing a full syntax
> summary rather than just saying "the SQL spec says you can grant
> privileges on columns but we don't support that yet".
Agreed. Patch attached and applied. I don't see any other cases of
this in our documentation.
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/ref/grant.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/grant.sgml,v
retrieving revision 1.64
diff -c -c -r1.64 grant.sgml
*** doc/src/sgml/ref/grant.sgml 1 Feb 2007 00:28:19 - 1.64
--- doc/src/sgml/ref/grant.sgml 7 Apr 2007 03:45:36 -
***
*** 520,533
! The SQL standard allows setting privileges for individual columns
! within a table:
!
!
! GRANT privileges
! ON table [ ( column [, ...] ) ] [, ...]
! TO { PUBLIC | username [, ...] } [ WITH GRANT OPTION ]
!
--- 520,527
! PostgreSQL does not support the SQL-standard
! functionality of setting privileges for individual columns.
Index: doc/src/sgml/ref/revoke.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/revoke.sgml,v
retrieving revision 1.42
diff -c -c -r1.42 revoke.sgml
*** doc/src/sgml/ref/revoke.sgml 31 Jan 2007 23:26:04 - 1.42
--- doc/src/sgml/ref/revoke.sgml 7 Apr 2007 03:45:37 -
***
*** 231,245
The compatibility notes of the command
! apply analogously to REVOKE. The syntax summary is:
!
!
! REVOKE [ GRANT OPTION FOR ] privileges
! ON object [ ( column [, ...] ) ]
! FROM { PUBLIC | username [, ...] }
! { RESTRICT | CASCADE }
!
! One of RESTRICT or CASCADE
is required according to the standard, but PostgreSQL
assumes RESTRICT by default.
--- 231,238
The compatibility notes of the command
! apply analogously to REVOKE.
! RESTRICT or CASCADE
is required according to the standard, but PostgreSQL
assumes RESTRICT by default.
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] UTF8MatchText
I do not understand this patch. You have defined two functions, UTF8MatchText() and UTF8MatchTextIC(), and the difference between them is that one calls CHAREQ and the other calls ICHAREQ, but just above those two functions you define the macros identically: #define CHAREQ(p1, p2)wchareq(p1, p2) #define ICHAREQ(p1, p2) wchareq(p1, p2) Why are there two functions? Also, can't you use one function and just pass a boolean to indicate whether case it be ignored? --- ITAGAKI Takahiro wrote: > "Andrew - Supernews" <[EMAIL PROTECTED]> wrote: > > > ITAGAKI> I think all "safe ASCII-supersets" encodings are comparable > > ITAGAKI> by bytes, not only UTF-8. > > > > This is false, particularly for EUC. > > Umm, I see. I updated the optimization to be used only for UTF8 case. > I also added some inlining hints that are useful on my machine (Pentium 4). > > > x1000 of LIKE '%foo% on 1 rows tables [ms] > encoding | HEAD | P1 | P2 | P3 > ---+---+---+---+--- > SQL_ASCII | 7094 | 7120 | 7063 | 7031 > LATIN1| 7083 | 7130 | 7057 | 7031 > UTF8 | 17974 | 10859 | 10839 | 9682 > EUC_JP| 17032 | 17557 | 17599 | 15240 > > - P1: UTF8MatchText() > - P2: P1 + __inline__ GenericMatchText() > - P3: P2 + __inline__ wchareq() > (The attached patch is P3.) > > Regards, > --- > ITAGAKI Takahiro > NTT Open Source Software Center > [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Concurrent psql v4 [WIP]
Please remove \cwait and supply an updated version with documentation. --- stark wrote: > > This is just an update against CVS. > > The interface is still as described at this URL: > > http://community.enterprisedb.com/concurrent/index.html > > It's true there isn't any documentation in the patch but I'm not sure we're > actually settled on the interface. > > I think our experience here is that the \cwait command was a mistake. You > never need it in intractive use, and you need to use it *religiously* when > writing regression tests. If you miss one your regression test will fail > randomly depending on the timing. Instead we should just have a psql setting > that makes it automatically wait before every connection switch. That ensures > you catch any bugs where a command fails to block when it should, and also > ensures you catch the output of an unblocked command as soon as you switch > connections to it. > > The other issue is the cursor behaviour. Currently it looks like below and it > starts a new pager for each block. I'm not sure this is really all that bad > myself but I have a feeling others will disagree. I'm not exactly sure what > the right behaviour is though, if this is an asynchronous command issued with > \cnowait then it would strange to suddenly start executing synchronously once > the first bit of data arrives. > > postgres[2]=# select * from generate_series(1,4); > generate_series > - >1 >2 >3 >4 > (10 rows) > > postgres[2]=# \set FETCH_COUNT 1 > > postgres[2]=# select * from generate_series(1,10); > generate_series > - >1 > (1 row) > > generate_series > - >2 > (1 row) > > generate_series > - >3 > (1 row) > > generate_series > - >4 > (1 row) > > generate_series > - > (0 rows) > > [ Attachment, skipping... ] > > > -- > Gregory Stark > EnterpriseDB http://www.enterprisedb.com > > ---(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 cleanly -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] UTF8MatchText
Bruce Momjian wrote: > > I do not understand this patch. You have defined two functions, > UTF8MatchText() and UTF8MatchTextIC(), and the difference between them > is that one calls CHAREQ and the other calls ICHAREQ, but just above > those two functions you define the macros identically: > > #define CHAREQ(p1, p2)wchareq(p1, p2) > #define ICHAREQ(p1, p2) wchareq(p1, p2) > > Why are there two functions? Also, can't you use one function and just > pass a boolean to indicate whether case it be ignored? Sorry, typo: Why are there two functions? Also, can't you use one function and just pass a boolean to indicate whether case should be ignored? -- > > --- > > ITAGAKI Takahiro wrote: > > "Andrew - Supernews" <[EMAIL PROTECTED]> wrote: > > > > > ITAGAKI> I think all "safe ASCII-supersets" encodings are comparable > > > ITAGAKI> by bytes, not only UTF-8. > > > > > > This is false, particularly for EUC. > > > > Umm, I see. I updated the optimization to be used only for UTF8 case. > > I also added some inlining hints that are useful on my machine (Pentium 4). > > > > > > x1000 of LIKE '%foo% on 1 rows tables [ms] > > encoding | HEAD | P1 | P2 | P3 > > ---+---+---+---+--- > > SQL_ASCII | 7094 | 7120 | 7063 | 7031 > > LATIN1| 7083 | 7130 | 7057 | 7031 > > UTF8 | 17974 | 10859 | 10839 | 9682 > > EUC_JP| 17032 | 17557 | 17599 | 15240 > > > > - P1: UTF8MatchText() > > - P2: P1 + __inline__ GenericMatchText() > > - P3: P2 + __inline__ wchareq() > > (The attached patch is P3.) > > > > Regards, > > --- > > ITAGAKI Takahiro > > NTT Open Source Software Center > > > > [ Attachment, skipping... ] > > > > > ---(end of broadcast)--- > > TIP 7: You can help support the PostgreSQL project by donating at > > > > http://www.postgresql.org/about/donate > > -- > Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us > EnterpriseDB http://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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
