[HACKERS] Re: [COMMITTERS] pgsql: psql: Improve expanded print output in tuples-only mode
On Sat, February 9, 2013 06:24, Peter Eisentraut wrote: psql: Improve expanded print output in tuples-only mode When there are zero result rows, in expanded mode, (No rows) is printed. So far, there was no way to turn this off. Now, when tuples-only mode is turned on, nothing is printed in this case. Good, that's definitely an improvement. But can we not remove that empty line alltogether in tuples-only mode? At the moment: $ echo '\dt+ diffs*' | psql --tuples-only public | diffs_2013_01 | table | aardvark | 8456 kB | public | diffs_2013_02 | table | aardvark | 7832 kB | $ The trailing empty line here makes almost as little sense as in the now amended case where there are zero rows ... (Of course, I realise that it's much more likely to break existing scripts, but should we then keep such illogical things forever at all cost?) Thanks, Erik Rijkers Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/8ade58a4ea318d0ab8548ab94e49a3b80fdbeb0d Modified Files -- src/bin/psql/print.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committ...@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] performance regression in 9.2 CTE with SRF function
Hello In Czech discussion group was reported performance regression of CTE query. I wrote a test, when I can show it. Execution on 9.2, 9.3 is about 9 sec, on 8.4, 9.1 is about 30ms with default work_mem ='1MB' optimal plan (8.4) QUERY PLAN Hash Join (cost=45.54..69.32 rows=441 width=4) (actual time=29.943..29.943 rows=0 loops=1) Output: x2.a Hash Cond: (x2.a = pl.a) CTE pl - HashAggregate (cost=17.50..18.39 rows=89 width=4) (actual time=6.723..7.016 rows=89 loops=1) Output: x.a - Seq Scan on x (cost=0.00..15.00 rows=1000 width=4) (actual time=0.026..3.390 rows=1000 loops=1) Output: x.a - Seq Scan on x2 (cost=24.25..41.75 rows=500 width=4) (actual time=21.178..21.757 rows=131 loops=1) Output: x2.a, x2.b Filter: (NOT (hashed SubPlan 2)) SubPlan 2 - CTE Scan on pl (cost=0.00..24.03 rows=89 width=4) (actual time=0.208..18.821 rows=1000 loops=1) Output: foo(pl.a) - Hash (cost=1.78..1.78 rows=89 width=4) (actual time=7.895..7.895 rows=89 loops=1) Output: pl.a - CTE Scan on pl (cost=0.00..1.78 rows=89 width=4) (actual time=6.733..7.592 rows=89 loops=1) Output: pl.a Total runtime: 30.046 ms suboptimal plan (9.3) QUERY PLAN Nested Loop (cost=18.39..346248.92 rows=441 width=4) (actual time=9373.295..9373.295 rows=0 loops=1) Output: x2.a Join Filter: (x2.a = pl.a) Rows Removed by Join Filter: 11837 CTE pl - HashAggregate (cost=17.50..18.39 rows=89 width=4) (actual time=4.363..4.539 rows=89 loops=1) Output: x.a - Seq Scan on public.x (cost=0.00..15.00 rows=1000 width=4) (actual time=0.031..2.133 rows=1000 loops=1) Output: x.a - CTE Scan on pl (cost=0.00..1.78 rows=89 width=4) (actual time=4.371..4.519 rows=89 loops=1) Output: pl.a - Materialize (cost=0.00..345562.50 rows=500 width=4) (actual time=0.203..105.051 rows=133 loops=89) Output: x2.a - Seq Scan on public.x2 (cost=0.00..345560.00 rows=500 width=4) (actual time=17.914..9330.645 rows=133 loops=1) Output: x2.a Filter: (NOT (SubPlan 2)) Rows Removed by Filter: 867 SubPlan 2 - CTE Scan on pl pl_1 (cost=0.00..468.59 rows=89000 width=4) (actual time=0.023..8.379 rows=566 loops=1000) Output: foo(pl_1.a) Total runtime: 9373.444 ms Higher work_mem 3MB fixes this issue QUERY PLAN ─ Hash Join (cost=712.37..736.15 rows=441 width=4) (actual time=38.024..38.024 rows=0 loops=1) Output: x2.a Hash Cond: (x2.a = pl.a) CTE pl - HashAggregate (cost=17.50..18.39 rows=89 width=4) (actual time=8.457..8.759 rows=89 loops=1) Output: x.a - Seq Scan on public.x (cost=0.00..15.00 rows=1000 width=4) (actual time=0.029..5.073 rows=1000 loops=1) Output: x.a - Seq Scan on public.x2 (cost=691.09..708.59 rows=500 width=4) (actual time=27.629..28.152 rows=105 loops=1) Output: x2.a, x2.b Filter: (NOT (hashed SubPlan 2)) Rows Removed by Filter: 895 SubPlan 2 - CTE Scan on pl pl_1 (cost=0.00..468.59 rows=89000 width=4) (actual time=0.328..24.224 rows=1000 loops=1) Output: foo(pl_1.a) - Hash (cost=1.78..1.78 rows=89 width=4) (actual time=9.650..9.650 rows=89 loops=1) Output: pl.a Buckets: 1024 Batches: 1 Memory Usage: 3kB - CTE Scan on pl (cost=0.00..1.78 rows=89 width=4) (actual time=8.468..9.346 rows=89 loops=1) Output: pl.a Total runtime: 38.153 ms There is terribly wrong estimation when work_mem is lower SubPlan 2 - CTE Scan on pl pl_1 (cost=0.00..468.59 rows=89000 width=4) (actual time=0.023..8.379 rows=566 loops=1000) Output: foo(pl_1.a) tables x and x2 are wery small - 64KB link to original thread - sorry it is in Czech language (but attached plans are in English :)) http://groups.google.com/group/postgresql-cz/browse_thread/thread/75e0e34e88950802?hl=cs Regards Pavel Stehule test-with.sql Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] function for setting/getting same timestamp during whole transaction
I might be confused here, but I think the point is that if you pass true as the third argument to set_config, the setting lasts only for the duration of the current transaction, like SET LOCAL. Which I think solves your problem. Yes, but at the end of transaction it is reset to the value it has before transaction (session level value), which can be nonempty. I wrote example about this problem lately in this thread.
Re: [HACKERS] Considering Gerrit for CFs
On 8 February 2013 10:23, Magnus Hagander mag...@hagander.net wrote: to solve two problems: 1. maximize the efficiency of existing reviewer time 2. make tooling not be an obstacle to getting new reviewers I think you are missing a fundamental part in this - which is 0. don't negatively affect the efficiency of existing committer time. Agreed. Process improvement is very important, but not more important than the process itself. What is the developer meeting for if not this discussion? Let's do some patch reviews and commits now and save the lets-make-it-better stufff for later. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SP-GiST for ranges based on 2d-mapping and quad-tree
Hi! On Mon, Dec 17, 2012 at 2:42 PM, Jeff Davis pg...@j-davis.com wrote: I have attached a patch with some significant edits. * In your patch, there was still an inconsistency between the comment for bounds_adjacent and the code. I refactored it to ensure it always takes the upper bound as boundA, and the lower bound as boundB, so that it can invert the inclusivities to create A..B to match the comments. * In the consistent method, you were inverting upper to be a lower bound and lower to be an upper bound. I don't understand why (perhaps I did the first time I read the patch), so I removed it. * It looks like the comments for which1/2 were inconsistent with the code. I tried to fix that. * I significantly refactored the comments and code for the consistent method. I had trouble understanding the original comments, particularly around the edge cases. Please take a look and see if it still matches your algorithm properly. This patch is not intended to be a final version (I didn't analyze my code carefully), but just to show you what I mean and how I interpret what the code is trying to do. You don't need to use my refactorings, but if not, the comments in your version need more improvement so I can understand. I found it easier to reason in terms of horizontal and vertical lines, and which quadrants they crossed, and then work out the edge cases. I'm not sure if that reasoning was correct, but it seemed to make more sense to me. Your comments and refactoring looks good for me. -- With best regards, Alexander Korotkov.
Re: [HACKERS] Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used
2013/1/31 Pavel Stehule pavel.steh...@gmail.com: I am sending rewritten code Nice. I think this will be very useful, and it looks like it now supports everything that printf() does for %s format specifiers, and it's good that %I and %L behave the same. Also the code is looking cleaner. It indirect width * and *n$ is supported. It needs little bit more code. There are a new question what should be result of format(%2$*1$s, NULL, hello) ??? My first thought is that a NULL width should be treated the same as no width at all (equivalent to width=0), rather than raising an exception. minor update - fix align NULL for %L You need to do the same for a NULL value with %s, which currently produces an empty string regardless of the width. The documentation also needs to be updated. I'm thinking perhaps format() should now have its own separate sub-section in the manual, rather than trying to cram it's docs into a single table row. I can help with the docs if you like. Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_prewarm
On Sun, Jun 24, 2012 at 1:36 PM, Cédric Villemain ced...@2ndquadrant.comwrote: Le samedi 23 juin 2012 02:47:15, Josh Berkus a écrit : The biggest problem with pgfincore from my point of view is that it only works under Linux, whereas I use a MacOS X machine for my development, and there is also Windows to think about. Even if that were fixed, though, I feel we ought to have something in the core distribution. This patch got more +1s than 95% of what gets proposed on hackers. Fincore is only a blocker to this patch if we think pgfincore is ready to be proposed for the core distribution. Do we? I'll make it ready for. (not a huge task). Hi Cedric, Can you please post the progress on this, if any. I am planning on polishing up pg_prewarm based on the reviews. As others have said, I don't see a reason why both can't coexist, maybe in pgxn. I am all ears if you think otherwise. Best regards, -- Gurjeet Singh http://gurjeet.singh.im/
[HACKERS] Fwd: Successful post to pgsql-hackers
Recently I have started getting these confirmations for every email I send to the mailing lists. I think it's related to the fact that I recently switched to using a new email address. How can I turn these notifications off? -- Forwarded message -- From: pgsql-hackers-ow...@postgresql.org Date: Sat, Feb 9, 2013 at 10:13 AM Subject: Successful post to pgsql-hackers To: Gurjeet Singh gurj...@singh.im Your message to the pgsql-hackers list, posted on Sat, 9 Feb 2013 10:11:05 -0500 with subject Re: pg_prewarm is currently being delivered. -- Gurjeet Singh http://gurjeet.singh.im/
Re: [HACKERS] Fwd: Successful post to pgsql-hackers
It's in your personal majordomo settings. I don't think it's related to that at all, but it's a flag you set on your subscription, so perhaps you set it by mistake. You shold be able to set it from https://mail.postgresql.org. The setting you're looking for is ackpost, and you'll want to turn it off. //Magnus On Sat, Feb 9, 2013 at 4:17 PM, Gurjeet Singh gurj...@singh.im wrote: Recently I have started getting these confirmations for every email I send to the mailing lists. I think it's related to the fact that I recently switched to using a new email address. How can I turn these notifications off? -- Forwarded message -- From: pgsql-hackers-ow...@postgresql.org Date: Sat, Feb 9, 2013 at 10:13 AM Subject: Successful post to pgsql-hackers To: Gurjeet Singh gurj...@singh.im Your message to the pgsql-hackers list, posted on Sat, 9 Feb 2013 10:11:05 -0500 with subject Re: pg_prewarm is currently being delivered. -- Gurjeet Singh http://gurjeet.singh.im/ -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fwd: Successful post to pgsql-hackers
On 9 February 2013 15:24, Magnus Hagander mag...@hagander.net wrote: It's in your personal majordomo settings. I don't think it's related to that at all, but it's a flag you set on your subscription, so perhaps you set it by mistake. Then I must have set it by mistake too, when I recently changed e-mail addresses. -- Regards, Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fwd: Successful post to pgsql-hackers
On Sat, Feb 9, 2013 at 4:31 PM, Peter Geoghegan peter.geoghega...@gmail.com wrote: On 9 February 2013 15:24, Magnus Hagander mag...@hagander.net wrote: It's in your personal majordomo settings. I don't think it's related to that at all, but it's a flag you set on your subscription, so perhaps you set it by mistake. Then I must have set it by mistake too, when I recently changed e-mail addresses. Hmm. I wonder if Alvaro may have accidentally switched the default, if it happened to more than one person. Alvaro, can you check? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fwd: Successful post to pgsql-hackers
I tried the lists page and disabled the 'selfcopy' since the 'ackpot' was kinda hidden under the mailing list names. I have updated the settings again to disable ackpost, and enable the selfcopy. This email will be test if that worked. BTW, I hope I understand what selfcopy is: send a copy to yourself. Why would that be turned on by default? On Sat, Feb 9, 2013 at 10:24 AM, Magnus Hagander mag...@hagander.netwrote: It's in your personal majordomo settings. I don't think it's related to that at all, but it's a flag you set on your subscription, so perhaps you set it by mistake. You shold be able to set it from https://mail.postgresql.org. The setting you're looking for is ackpost, and you'll want to turn it off. //Magnus On Sat, Feb 9, 2013 at 4:17 PM, Gurjeet Singh gurj...@singh.im wrote: Recently I have started getting these confirmations for every email I send to the mailing lists. I think it's related to the fact that I recently switched to using a new email address. How can I turn these notifications off? -- Forwarded message -- From: pgsql-hackers-ow...@postgresql.org Date: Sat, Feb 9, 2013 at 10:13 AM Subject: Successful post to pgsql-hackers To: Gurjeet Singh gurj...@singh.im Your message to the pgsql-hackers list, posted on Sat, 9 Feb 2013 10:11:05 -0500 with subject Re: pg_prewarm is currently being delivered. -- Gurjeet Singh http://gurjeet.singh.im/ -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Gurjeet Singh http://gurjeet.singh.im/
Re: [HACKERS] [Review] Add SPI_gettypmod() to return a field's typemod from a TupleDesc
On Tue, Jul 3, 2012 at 8:33 AM, Robert Haas robertmh...@gmail.com wrote: On Thu, Jun 28, 2012 at 9:49 AM, Robert Haas robertmh...@gmail.com wrote: On Mon, Jun 18, 2012 at 3:29 PM, Amit Kapila amit.kap...@huawei.com wrote: [ review ] Chetan, this patch is waiting for an update from you. If you'd like this to get committed this CommitFest, we'll need an updated patch soon. Hearing no response, I've marked this patch Returned with Feedback. Hello everyone, I thought I'd take a stab at helping finish this patch. I have made an attempt at adding documentation and replacing the couple of XXX comments. I'll add it to the next commitfest. Regards, Mark add_spigettypmod-20130209.diff Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch: log level change in gistsplit.c
Josh Hansen josh.han...@zonarsystems.com writes: We've been seeing these same messages flying by our logs for years: 2012-12-13 22:28:07 GMT LOG: picksplit method for column 2 of index xxx_idx doesn't support secondary split I see from the linked message that Tom Lane made the recommendation of changing the loglevel from LOG to DEBUG1. As such, I've gone ahead and made this change and attached the patch file. http://archives.postgresql.org/pgsql-general/2007-08/msg01810.php I got annoyed by this message again while poking at gistsplit bugs this week, so done for 9.3. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgcrypto seeding problem when ssl=on
On Sun, Jan 13, 2013 at 07:01:07PM -0500, Noah Misch wrote: On Sun, Jan 13, 2013 at 05:46:12PM -0500, Tom Lane wrote: Marko Kreen mark...@gmail.com writes: On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch n...@leadboat.com wrote: How about instead calling RAND_cleanup() after each backend fork? Attached is a patch that adds RAND_cleanup() to fork_process(). I remain unconvinced that this is the best solution. Anybody else have an opinion? I'd describe it as the clearly-secure solution. The biggest hazard I see is the drain on system entropy. A system having only a blocking /dev/random could suddenly find itself entropy-exhausted after installing the minor upgrade. Backends could block waiting for system entropy to accumulate. That's not directly a problem on Linux. However, if other programs on the system read from /dev/random, the pressure from PostgreSQL's /dev/urandom usage may make those programs wait longer for entropy. I'm also comfortable with the security of Marko's original proposal, modulo it happening in each backend shortly after fork, not merely in pgcrypto. OpenSSL's ssl module uses a similar method, and one of the papers I cited describes it. (If anything, OpenSSL is less cautious. It uses time(), not gettimeofday().) The performance characteristics of this approach are easier to guess: one system call if we use MyProcPid + gettimeofday(), zero if we use MyProcPid + MyStartTime. You proposed mixing gettimeofday() into the postmaster's entropy pool after each fork. I wouldn't be too concerned if we did it that way, but my quick literature review did not turn up any similar ideas. Given that this is strictly more expensive than the previous method, I don't recommend it. Overall, I'd recommend mixing in MyProcPid and MyStartTime after each fork. I neglected to ping this for the last back-branch releases. May we adopt one of the above fixes and issue a CVE with the next releases? Though I've stated my preference, all three proposals would be major improvements over the present, quietly-vulnerable state. Thanks, nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used
2013/2/9 Dean Rasheed dean.a.rash...@gmail.com: 2013/1/31 Pavel Stehule pavel.steh...@gmail.com: I am sending rewritten code Nice. I think this will be very useful, and it looks like it now supports everything that printf() does for %s format specifiers, and it's good that %I and %L behave the same. Also the code is looking cleaner. It indirect width * and *n$ is supported. It needs little bit more code. There are a new question what should be result of format(%2$*1$s, NULL, hello) ??? My first thought is that a NULL width should be treated the same as no width at all (equivalent to width=0), rather than raising an exception. minor update - fix align NULL for %L You need to do the same for a NULL value with %s, which currently produces an empty string regardless of the width. have others same opinion? Usually I don't like hide NULLs, but this is corner case (and specific function) and I have not strong opinion on this issue. The documentation also needs to be updated. I'm thinking perhaps format() should now have its own separate sub-section in the manual, rather than trying to cram it's docs into a single table row. I can help with the docs if you like. please, if you can, write it. I am sure, so you do it significantly better than me. Thank you Pavel Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [JDBC] JPA + enum == Exception
This is not entirely unrelated to the discussions about allowing broader use of automatic casting server-side. It seems to me that on one side of the argument is the idea that strict typing reduces bugs and doesn't lead to problems with ambiguity, especially as things change; and on the other side the argument is that where no ambiguity exists we would make life easier for developers of applications or access tools if we relexed things beyond what the related specifications require, and that not doing so discourages adoption. I think that all the same arguments apply here with equal force, on both sides of the issue. The problem with this debate has always been that both sides are completely right. Those are always the toughest to resolve. It comes down to which evils we tolerate to garner which benefits. It seems that in such cases inertia tends to win. I'm not so sure that it should. An ideal solution would find some way to address the concerns of both sides, but so far that has eluded us when it comes to the type system. As for me, right way would be to allow exactly same casting as when using literals. Because now there are a lot of complaints like It's driver problem because it works in psql. Best regards, Vitalii Tymchyshyn
Re: PATCH: Split stats file per database WAS: [HACKERS] autovacuum stress-testing our system
On Tue, Feb 5, 2013 at 2:31 PM, Tomas Vondra t...@fuzzy.cz wrote: We do not already have this. There is no relevant spec. I can't see how this could need pg_dump support (but what about pg_upgrade?) pg_dump - no pg_upgrage - IMHO it should create the pg_stat directory. I don't think it could convert statfile into the new format (by splitting it into the pieces). I haven't checked but I believe the default behavior is to delete it as there might be new fields / slight changes of meaning etc. Right, I have no concerns with pg_upgrade any more. The pg_stat will inherently get created by the initdb of the new cluster (because the initdb will done with the new binaries with your patch in place them). pg_upgrade currently doesn't copy over global/pgstat.stat. So that means the new cluster doesn't have the activity stats either way, patch or unpatched. So if it is not currently a problem it will not become one under the proposed patch. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fwd: Successful post to pgsql-hackers
On 09-02-2013 13:45, Gurjeet Singh wrote: BTW, I hope I understand what selfcopy is: send a copy to yourself. Why would that be turned on by default? If you want to reply to yourself... -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Further info about picksplit-doesn't-support-secondary-split whining
I've spent the afternoon reading and documenting gistsplit.c, and finally feel like I understand what's going on in there, particularly with respect to the secondary-split logic of log-spam infamy. I'll be committing the results of that in a bit, but meanwhile: what I now realize is that the fallback secondary split implementation in supportSecondarySplit() is not especially awful, and opclass PickSplit functions would generally need fairly invasive changes to do better than that. They'd need to try to build out from a pair of predetermined union values, rather than selecting a split entirely on their own. The comment I'm going to add about this looks like so: /* * This is the Split Vector to be returned by the PickSplit method. * PickSplit should fill the indexes of tuples to go to the left side into * spl_left[], and those to go to the right into spl_right[] (note the method * is responsible for palloc'ing both of these arrays!). The tuple counts * go into spl_nleft/spl_nright, and spl_ldatum/spl_rdatum must be set to * the union keys for each side. * * If spl_ldatum_exists or spl_rdatum_exists is true, then we are performing * a secondary split using a non-first index column. In this case some * decisions have already been made about a page split, and the set of tuples * being passed to PickSplit is just the tuples about which we are undecided. * spl_ldatum/spl_rdatum then contain the union keys for the tuples already * chosen to go left or right. Ideally the PickSplit method should take those * keys into account while deciding what to do with the remaining tuples. * In any case, it should union the given tuples' keys into the existing * spl_ldatum/spl_rdatum values rather than just setting those values from * scratch, and then set spl_ldatum_exists/spl_rdatum_exists to false to show * it has done this. * * If the PickSplit method fails to clear spl_ldatum_exists/spl_rdatum_exists, * the core GiST code will make its own decision about how to merge the * secondary-split results with the previously-chosen tuples, and will then * recompute the union keys properly. This is a workable though often not * optimal approach. */ Looking around shows that there is only one opclass PickSplit function that makes any attempt to support secondary split directly, namely gist_box_picksplit; and it's only handling the case in its fallbackSplit code path, which is hopefully very seldom taken; and the code that it has there is actually stupider than the fallback implementation in gistsplit.c, because it's *not* making any attempt to build out from the given ranges, it's just adding them in after the fact. gistsplit.c can do that for itself. What's more, it takes the trouble to see which half of the secondary split goes better with which half of the primary split, useful logic that is being short-circuited by the inferior code in gist_box_picksplit. So IMO that's completely broken, and we should just rip out lines 226-234 of gistproc.c. That would leave us with no, zero, opclasses that don't provoke the picksplit method doesn't support secondary split griping from gistsplit.c. Which makes one question why that message is there at all, much less at LOG level. It may have been intended to spur development of smarter PickSplit functions, but since nothing has been done towards that in over five years, I'm not holding my breath for it to happen. I now think we should just remove that message entirely, and in the back branches too. There's no reason to expect that we'll ever have all the GiST opclasses upgraded to do secondary splits internally. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fwd: Successful post to pgsql-hackers
Magnus Hagander escribió: On Sat, Feb 9, 2013 at 4:31 PM, Peter Geoghegan peter.geoghega...@gmail.com wrote: On 9 February 2013 15:24, Magnus Hagander mag...@hagander.net wrote: It's in your personal majordomo settings. I don't think it's related to that at all, but it's a flag you set on your subscription, so perhaps you set it by mistake. Then I must have set it by mistake too, when I recently changed e-mail addresses. Hmm. I wonder if Alvaro may have accidentally switched the default, if it happened to more than one person. Alvaro, can you check? I hadn't touched this, but Andres Freund had already complained about this before. I just checked and yes, it seems that the flag to send a confirmation for each post is set. I have reset it. I also took the opportunity to set the flags to send confirmation emails when a posting is rejected or stalled for moderation. We discussed this previously (Pavel Stehule complained about it). I changed the defaults for new subscribers, and also the flags values for all existing subscribers, note. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Identity projection
On Saturday, February 09, 2013 9:03 AM Tom Lane wrote: Amit kapila amit.kap...@huawei.com writes: if (!is_projection_capable_plan(result_plan) compare_tlist_exprs(sub_tlist, result_plan-targetlist) ) Sorry, the check I suggested in last mail should be as below: if (!is_projection_capable_plan(result_plan) !compare_tlist_exprs(sub_tlist, result_plan-targetlist) ) You know, I was thinking that compare_tlist_exprs() was a pretty unhelpfully-chosen name for a function returning boolean, and this thinko pretty much proves the point. It'd be better to call it something like equivalent_tlists(), tlists_are_equivalent(), etc. (I'm not caring for the emphasis on the exprs either, because I think it'll also be necessary to compare resjunk fields for instance.) The fields which cannot be compared are resname, resorigtbl, resorigcol as these gets cleared in planner. I am not sure about fields resno and ressortgroupref, but I will check in more detail before sending patch. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Department of Redundancy Department: makeNode(FuncCall) division
Folks,
Per suggestions and lots of help from Andrew Gierth, please find
attached a patch to clean up the call sites for FuncCall nodes, which
I'd like to expand centrally rather than in each of the 37 (or 38, but
I only redid 37) places where it's called. The remaining one is in
src/backend/nodes/copyfuncs.c, which has to be modified for any
changes in the that struct anyhow.
The immediate purpose is two-fold: to reduce some redundancies, which
I believe is worth doing in and of itself, and to prepare for adding
FILTER on aggregates from the spec, and possibly other things in
the aggregate function part of the spec.
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
*** a/src/backend/nodes/makefuncs.c
--- b/src/backend/nodes/makefuncs.c
***
*** 508,510 makeDefElemExtended(char *nameSpace, char *name, Node *arg,
--- 508,530
return res;
}
+
+ /*
+ * makeFuncCall -
+ * set up to call a function. DRY!
+ */
+ FuncCall *
+ makeFuncCall(List *name, List *args, int location)
+ {
+ FuncCall *n = makeNode(FuncCall);
+ n-funcname = name;
+ n-args = args;
+ n-location = location;
+ n-agg_order = NIL;
+ n-agg_star = FALSE;
+ n-agg_distinct = FALSE;
+ n-func_variadic = FALSE;
+ n-over = NULL;
+ return n;
+ }
+
*** a/src/backend/parser/gram.y
--- b/src/backend/parser/gram.y
***
*** 10344,10359 a_expr:c_expr
{ $$ = $1; }
}
| a_expr AT TIME ZONE a_expr%prec AT
{
! FuncCall *n = makeNode(FuncCall);
! n-funcname =
SystemFuncName(timezone);
! n-args = list_make2($5, $1);
! n-agg_order = NIL;
! n-agg_star = FALSE;
! n-agg_distinct = FALSE;
! n-func_variadic = FALSE;
! n-over = NULL;
! n-location = @2;
! $$ = (Node *) n;
}
/*
* These operators must be called out explicitly in order to
make use
--- 10344,10352
}
| a_expr AT TIME ZONE a_expr%prec AT
{
! $$ = (Node *)
makeFuncCall(SystemFuncName(timezone),
!
list_make2($5, $1),
!
@2);
}
/*
* These operators must be called out explicitly in order to
make use
***
*** 10405,10517 a_expr:c_expr
{ $$ = $1; }
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP,
~~, $1, $3, @2); }
| a_expr LIKE a_expr ESCAPE a_expr
{
! FuncCall *n = makeNode(FuncCall);
! n-funcname =
SystemFuncName(like_escape);
! n-args = list_make2($3, $5);
! n-agg_order = NIL;
! n-agg_star = FALSE;
! n-agg_distinct = FALSE;
! n-func_variadic = FALSE;
! n-over = NULL;
! n-location = @2;
! $$ = (Node *)
makeSimpleA_Expr(AEXPR_OP, ~~, $1, (Node *) n, @2);
}
| a_expr NOT LIKE a_expr
{ $$ = (Node *) makeSimpleA_Expr(AEXPR_OP,
!~~, $1, $4, @2); }
| a_expr NOT LIKE a_expr ESCAPE a_expr
{
! FuncCall *n = makeNode(FuncCall);
! n-funcname =
SystemFuncName(like_escape);
! n-args = list_make2($4, $6);
! n-agg_order = NIL;
! n-agg_star = FALSE;
!
