Re: [PATCHES] xpath_array with namespaces support
What's with this patch?
I do not see it in unapplied patches list, neither it was commited...
What we have now in CVS is not a good thing.
On 4/10/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
Here is new version that adds following changes:
4. Function is now strict, per discussion.
5. Return empty array in case when XPath expression detects nothing
(previously, NULL was returned in such case), per discussion.
6. (bugfix) Work with fragments with prologue: select xpath('/a',
'?xml version=1.0?a /b /'); // now XML datum is always wrapped
with dummy x.../x, XML prologue simply goes away (if any).
7. Some cleanup.
On 4/4/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
The patch attached contains following changes:
1. The function name xmlpath() is changed to xpath();
2. Approach of passing of namepspace mappings to the function is changed:
now that array (the 3rd argument) should be a 2-dimentional array with the
length of the second axis = 2 (e.g., ARRAY[ARRAY['a1', 'http://a1'],
ARRAY['a2', 'http://a2'], ARRAY['a2', 'http://a2']]);
3. Description of xpath() function in docs (I'm sorry for possible
mistakes in English and docbook formatting, please check it...)
--
Best regards,
Nikolay
---(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] Re: [COMMITTERS] pgsql: Some further performance tweaks for planning large inheritance
Does this eliminate problems with using a large number of tablespaces? --- Tom Lane wrote: Log Message: --- Some further performance tweaks for planning large inheritance trees that are mostly excluded by constraints: do the CE test a bit earlier to save some adjust_appendrel_attrs() work on excluded children, and arrange to use array indexing rather than rt_fetch() to fetch RTEs in the main body of the planner. The latter is something I'd wanted to do for awhile anyway, but seeing list_nth_cell() as 35% of the runtime gets one's attention. Modified Files: -- pgsql/src/backend/optimizer/path: allpaths.c (r1.162 - r1.163) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/path/allpaths.c.diff?r1=1.162r2=1.163) clausesel.c (r1.84 - r1.85) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/path/clausesel.c.diff?r1=1.84r2=1.85) costsize.c (r1.180 - r1.181) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/path/costsize.c.diff?r1=1.180r2=1.181) pgsql/src/backend/optimizer/plan: createplan.c (r1.228 - r1.229) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/createplan.c.diff?r1=1.228r2=1.229) planagg.c (r1.30 - r1.31) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/planagg.c.diff?r1=1.30r2=1.31) planmain.c (r1.99 - r1.100) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/planmain.c.diff?r1=1.99r2=1.100) pgsql/src/backend/optimizer/util: pathnode.c (r1.138 - r1.139) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/util/pathnode.c.diff?r1=1.138r2=1.139) plancat.c (r1.133 - r1.134) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/util/plancat.c.diff?r1=1.133r2=1.134) relnode.c (r1.86 - r1.87) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/util/relnode.c.diff?r1=1.86r2=1.87) pgsql/src/backend/utils/adt: selfuncs.c (r1.232 - r1.233) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/selfuncs.c.diff?r1=1.232r2=1.233) pgsql/src/include/nodes: relation.h (r1.140 - r1.141) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/nodes/relation.h.diff?r1=1.140r2=1.141) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- 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 6: explain analyze is your friend
Re: [PATCHES] xpath_array with namespaces support
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.
---
Nikolay Samokhvalov wrote:
Here is new version that adds following changes:
4. Function is now strict, per discussion.
5. Return empty array in case when XPath expression detects nothing
(previously, NULL was returned in such case), per discussion.
6. (bugfix) Work with fragments with prologue: select xpath('/a',
'?xml version=1.0?a /b /'); // now XML datum is always wrapped
with dummy x.../x, XML prologue simply goes away (if any).
7. Some cleanup.
On 4/4/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
The patch attached contains following changes:
1. The function name xmlpath() is changed to xpath();
2. Approach of passing of namepspace mappings to the function is changed:
now that array (the 3rd argument) should be a 2-dimentional array with the
length of the second axis = 2 (e.g., ARRAY[ARRAY['a1', 'http://a1'],
ARRAY['a2', 'http://a2'], ARRAY['a2', 'http://a2']]);
3. Description of xpath() function in docs (I'm sorry for possible
mistakes in English and docbook formatting, please check it...)
On 4/3/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Nikolay Samokhvalov wrote:
On 3/22/07, Peter Eisentraut [EMAIL PROTECTED] wrote:
Bruce Momjian wrote:
Patch applied.
This code seems to think that if an xml datum starts with ?xml it's
a
document. That is completely bogus.
Agreed. I'll fix it.
Nikolay, it has been a week, and I have see no fixes from you in
response to requests from Peter. If the patch doesn't arrive in 1-2
days, I will have to revert your patch and it will be kept for 8.4.
Feature freeze was April 1, 2007.
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
EnterpriseDB
http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Best regards,
Nikolay
--
Best regards,
Nikolay
[ Attachment, skipping... ]
--
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 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] xpath_array with namespaces support
Thanks, added to queue.
---
Nikolay Samokhvalov wrote:
What's with this patch?
I do not see it in unapplied patches list, neither it was commited...
What we have now in CVS is not a good thing.
On 4/10/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
Here is new version that adds following changes:
4. Function is now strict, per discussion.
5. Return empty array in case when XPath expression detects nothing
(previously, NULL was returned in such case), per discussion.
6. (bugfix) Work with fragments with prologue: select xpath('/a',
'?xml version=1.0?a /b /'); // now XML datum is always wrapped
with dummy x.../x, XML prologue simply goes away (if any).
7. Some cleanup.
On 4/4/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
The patch attached contains following changes:
1. The function name xmlpath() is changed to xpath();
2. Approach of passing of namepspace mappings to the function is
changed:
now that array (the 3rd argument) should be a 2-dimentional array with the
length of the second axis = 2 (e.g., ARRAY[ARRAY['a1', 'http://a1'],
ARRAY['a2', 'http://a2'], ARRAY['a2', 'http://a2']]);
3. Description of xpath() function in docs (I'm sorry for possible
mistakes in English and docbook formatting, please check it...)
--
Best regards,
Nikolay
--
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 6: explain analyze is your friend
Re: [PATCHES] guc patch: Make variables fall back to default values
Patch applied by Peter. Thanks. --- Joachim Wieland wrote: On Mon, Apr 02, 2007 at 07:25:46PM -0400, Bruce Momjian wrote: I assume this patch is not ready for 8.3, so I added a URL to the TODO list for it. I have reworked it such that it ignores custom variable templates as Tom suggested. Attached is the new version. Joachim [ Attachment, skipping... ] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- 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 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] parser dilemma
Tom Lane wrote: So I think attaching a precedence to the GENERATED keyword is dangerous. Especially when we have a good workaround which would just require use of () around certain postfix-operator expressions. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [COMMITTERS] pgsql: Some further performance tweaks for planning large inheritance
Bruce Momjian [EMAIL PROTECTED] writes: Does this eliminate problems with using a large number of tablespaces? No, it doesn't have anything particular to do with tablespaces. It gets rid of some bottlenecks that become noticeable with a large number of child tables. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] parser dilemma
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: So I think attaching a precedence to the GENERATED keyword is dangerous. Especially when we have a good workaround which would just require use of () around certain postfix-operator expressions. Yeah, I'm leaning to the idea that removing postfix operators from b_expr is the least bad solution. One thing that would have to be looked at is the rules in ruleutils.c for suppressing unnecessary parentheses when reverse-listing parsetrees. It might be safest to just never suppress them around a postfix operator. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] Re: [COMMITTERS] pgsql: Some further performance tweaks for planning large inheritance
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Does this eliminate problems with using a large number of tablespaces? No, it doesn't have anything particular to do with tablespaces. It gets rid of some bottlenecks that become noticeable with a large number of child tables. Yes, but I thought the problem with many tablespaces was the cost of referencing them as child tables. Simon? -- 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] [HACKERS] Full page writes improvement, code update
Hi, I don't insist the name and the default of the GUC parameter. I'm afraid wal_fullpage_optimization = on (default) makes some confusion because the default behavior becomes a bit different on WAL itself. I'd like to have some more opinion on this. Zeugswetter Andreas ADI SD wrote: With DBT-2 benchmark, I've already compared the amount of WAL. The result was as follows: Amount of WAL after 60min. run of DBT-2 benchmark wal_add_optimization_info = off (default) 3.13GB how about wal_fullpage_optimization = on (default) wal_add_optimization_info = on (new case) 3.17GB - can be optimized to 0.31GB by pg_compresslog. So the difference will be around a couple of percents. I think this is very good figure. For information, DB Size: 12.35GB (120WH) Checkpoint timeout: 60min. Checkpoint occured only once in the run. Unfortunately I think DBT-2 is not a good benchmark to test the disabled wal optimization. The test should contain some larger rows (maybe some updates on large toasted values), and maybe more frequent checkpoints. Actually the poor ratio between full pages and normal WAL content in this benchmark is strange to begin with. Tom fixed a bug recently, and it would be nice to see the new ratio. Have you read Tom's comment on not really having to be able to reconstruct all record types from the full page image ? I think that sounded very promising (e.g. start out with only heap insert/update). Then: - we would not need the wal optimization switch (the full page flag would always be added depending only on backup) - pg_compresslog would only remove such full page images where it knows how to reconstruct a normal WAL record from - with time and effort pg_compresslog would be able to compress [nearly] all record types's full images (no change in backend) I don't think replacing LSN works fine. For full recovery to the current time, we need both archive log and WAL. Replacing LSN will make archive log LSN inconsistent with WAL's LSN and the recovery will not work. WAL recovery would have had to be modified (decouple LSN from WAL position during recovery). An archive log would have been a valid WAL (with appropriate LSN advance records). Reconstruction to regular WAL is proposed as pg_decompresslog. We should be careful enough not to make redo routines confused with the dummy full page writes, as Simon suggested. So far, it works fine. Yes, Tom didn't like LSN replacing eighter. I withdraw my concern regarding pg_decompresslog. Your work in this area is extremely valuable and I hope my comments are not discouraging. Thank you Andreas -- - Koichi Suzuki ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Dead Space Map version 3 (simplified)
Heikki Linnakangas wrote: The way you update the DSM is quite interesting. When a page is dirtied, the BM_DSM_DIRTY flag is set in the buffer descriptor. The corresponding bit in the DSM is set lazily in FlushBuffer whenever BM_DSM_DIRTY is set. That's a clever way to avoid contention on updates. But does it work for tables that have a small hot part that's updated very frequently? I think there is no problem. Bloating will make pages including the unnecessary area which will not be accessed. Soon, those pages will be registered into DSM. Or, though it expands however, do you assume accessing all pages equally? -- Hiroki Kataoka [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
