Re: [HACKERS] Command Triggers, patch v11
Tom Lane schrieb: >Andres Freund writes: >> I refreshed the patch so it works again on current HEAD. Basically >some >> trivial fixes and dfd26f9c5f371437f243249025863ea9911aacaa. The >latter doesn't >> seem necessary to me after the changes, so I simply ditched it. Am I >missing >> something? > >No, that was only needed because execMain.c was overriding somebody >else's tuple receiver. If you're putting the right receiver into the >QueryDesc to start with, it shouldn't be necessary. > >I'm confused by this though: > >> This basically includes a revert of >d8fb1f9adbddd1eef123d66a89a9fc0ecd96f60b > >I don't find that commit ID anywhere. That should have been the aforementioned commit. Must have screwed up the copy&paste buffer. Sorry for that. Andres Please excuse the brevity and formatting - I am writing this on my mobile phone. -- 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] Command Triggers, patch v11
"anara...@anarazel.de" schrieb: > > >Thom Brown schrieb: > >>On 2 March 2012 23:33, Thom Brown wrote: >>> On 2 March 2012 22:32, Dimitri Fontaine >>wrote: >>>>>> test=# CREATE TABLE badname (id int, a int, b text); >>>>>> ERROR: invalid relation name: badname >>>>>> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, >>''::text b; >>>>>> SELECT 1 >>>>>> >>>>>> This doesn't even get picked up by ANY COMMAND. >>>> >>>> I think Andres should add an entry for his patch on the commitfest. >> Is >>>> it ok? >>> >>> I'll try Andres' patch this weekend while I test yours. >> >>Actually no matter which patch I apply first, they cause the other to >>fail to apply. >I will try to fix that on the plain tomorrow (to NYC) but I am not yet >sure when/where I will have internet access again. One more try: To the list. Andres Please excuse the brevity and formatting - I am writing this on my mobile phone. -- 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] logical decoding - GetOldestXmin
Hi, Robert Haas schrieb: >On Fri, Dec 14, 2012 at 7:19 PM, Andres Freund >wrote: >> On 2012-12-14 14:01:30 -0500, Robert Haas wrote: >>> On Fri, Dec 14, 2012 at 6:46 AM, Andres Freund > wrote: >>> > Just moving that tidbit inside the lock seems to be the pragmatic >>> > choice. GetOldestXmin is called >>> > >>> > * once per checkpoint >>> > * one per index build >>> > * once in analyze >>> > * twice per vacuum >>> > * once for HS feedback messages >>> > >>> > Nothing of that occurs frequently enough that 5 instructions will >make a >>> > difference. I would be happy to go an alternative path, but right >now I >>> > don't see any nice one. A "already_locked" parameter to >GetOldestXmin >>> > seems to be a cure worse than the disease. >>> >>> I'm not sure that would be so bad, but I guess I question the need >to >>> do it this way at all. Most of the time, if you need to advertise >>> your global xmin, you use GetSnapshotData(), not GetOldestXmin(), >and >>> I guess I'm not seeing why that wouldn't also work here. Am I dumb? >> >> I wondered upthread whether that would be better: >> >> On 2012-12-13 21:03:44 +0100, Andres Freund wrote: >>> Another alternative to this would be to get a snapshot with >>> GetSnapshotData(), copy the xmin to the logical slot, then call >>> ProcArrayEndTransaction(). But that doesn't really seem to be nicer >to >>> me. >> >> Not sure why I considered it ugly anymore, but it actually has a >> noticeable disadvantage. GetOldestXmin is nicer is than >GetSnapshotData >> as the latter set a fairly new xid as xmin whereas GetOldestXmin >returns >> the actual current xmin horizon. Thats preferrable because it allows >us >> to start up more quickly. snapbuild.c can only start building a >snapshot >> once it has seen a xl_running_xact with oldestRunningXid >= >> own_xmin. Otherwise we cannot be sure that no relevant catalog tuples >> have been removed. > >I'm a bit confused. Are you talking about the difference between >RecentGlobalXmin and RecentXmin? I think GetSnapshotData() updates >both. The problem is that at the time GetSnapshotData returns the xmin horizon might have gone upwards and tuples required for decoding might get removed by other backends. That needs to be prevented while holding the procarray lock exclusively. Does it make more sense now? Andres --- Please excuse the brevity and formatting - I am writing this on my mobile phone. -- 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] buffer assertion tripping under repeat pgbench load
Tom Lane schrieb:
>Greg Smith writes:
>> To try and speed up replicating this problem I switched to a smaller
>> database scale, 100, and I was able to get a crash there. Here's the
>
>> latest:
>
>> 2012-12-26 00:01:19 EST [2278]: WARNING: refcount of
>base/16384/57610
>> blockNum=118571, flags=0x106 is 1073741824 should be 0, globally: 0
>> 2012-12-26 00:01:19 EST [2278]: WARNING: buffers with non-zero
>refcount
>> is 1
>> TRAP: FailedAssertion("!(RefCountErrors == 0)", File: "bufmgr.c",
>Line:
>> 1720)
>
>> That's the same weird 1073741824 count as before. I was planning to
>> dump some index info, but then I saw this:
>
>> $ psql -d pgbench -c "select relname,relkind,relfilenode from
>pg_class
>> where relfilenode=57610"
>> relname | relkind | relfilenode
>> --+-+-
>> pgbench_accounts | r | 57610
>
>> Making me think this isn't isolated to being an index problem.
>
>Yeah, that destroys my theory that there's something broken about index
>management specifically. Now we're looking for something that can
>affect any buffer's refcount, which more than likely means it has
>nothing to do with the buffer's contents ...
>
>> I tried
>> to soldier on with pg_filedump anyway. It looks like the last
>version I
>> saw there (9.2.0 from November) doesn't compile anymore:
>
>Meh, looks like it needs fixes for Heikki's int64-xlogrecoff patch.
>I haven't gotten around to doing that yet, but would gladly take a
>patch if anyone wants to do it. However, I now doubt that examining
>the buffer content will help much on this problem.
>
>Now that we know the bug's reproducible on smaller instances, could you
>put together an exact description of what you're doing to trigger
>it? What is the DB configuration, pgbench parameters, etc?
>
>Also, it'd be worthwhile to just repeat the test a few more times
>to see if there's any sort of pattern in which buffers get affected.
>I'm now suspicious that it might not always be just one buffer,
>for example.
I don't think its necessarily only one buffer - if I read the above output
correctly Greg used the suggested debug output which just put the elog(WARN)
before the Assert...
Greg, could you output all "bad" buffers and only assert after the loop if
there was at least one refcounted buffer?
Andres
---
Please excuse the brevity and formatting - I am writing this on my mobile phone.
--
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] fix bgworkers in EXEC_BACKEND
Tom Lane schrieb: >Andres Freund writes: >> I am still worried about the following scenario in the EXEC_BACKEND >case: > >> 1) postmaster starts >> 2) reads config >> 3) executes _PG_init for shared_preload_libraries >> 4) library 'abc' gets config value 'abc.num_workers = 2' and >registers as many workers >> 5) some time goes by, workers, backends start >> 6) abc.num_workers gets changed to 3, SIGHUP > >This is broken whether it's EXEC_BACKEND or not: you don't get to >change >anything that determines the number of workers post-startup. >num_workers should have been declared PGC_POSTMASTER. BTW, I think it happens not to be broken in the non EXEC_BACKEND case because the registration point for bgworkers is _PG_init which will only be called once without EXEC_BACKEND, so config changes to SIGHUP'able variables won't change a thing dangerous as the bgworker stuff is all set up. Andres --- Please excuse the brevity and formatting - I am writing this on my mobile phone. -- 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] enhanced error fields
Robert Haas schrieb:
>On Sat, Dec 29, 2012 at 4:30 PM, Peter Geoghegan
> wrote:
>> Ascertaining the identity of the object in question perfectly
>> unambiguously, so that you can safely do something like lookup a
>> comment on the object, seems like something way beyond what I'd
>> envisioned for this feature. Why should the comment be useful in an
>> error handler anyway? At best, that seems like a nice-to-have extra
>to
>> me. The vast majority are not even going to think about the ambiguity
>> that may exist. They'll just write:
>>
>> if (constraint_name == "upc")
>> MessageBox("That is not a valid barcode.");
>
>The people who are content to do that don't need this patch at all.
>They can just apply a regexp to the message that comes back from the
>server and then set constraint_name based on what pops out of the
>regex. And then do just what you did there.
Easier said than done if you're dealing with pg installations with different
lc_messages...
Andres
---
Please excuse the brevity and formatting - I am writing this on my mobile phone.
--
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: [PATCH 1/2] Provide a common malloc wrappers and palloc et al. emulation for frontend'ish environs
Tom Lane schrieb: >Andres Freund writes: >> On 2013-01-09 11:27:46 -0500, Tom Lane wrote: >>> I'd prefer posting a single message with the discussion and the >>> patch(es). If you think it's helpful to split a patch into separate >>> parts for reviewing, add multiple attachments. But my experience is >>> that such separation isn't nearly as useful as you seem to think. > >> Well, would it have been better if xlog reading, ilist, binaryheap, >this >> cleanup, etc. have been in the same patch? They have originated out >of >> the same work... >> Even the splitup in this thread seems to have helped as youve jumped >on >> the patches where you could give rather quick input (static >> relpathbackend(), central Assert definitions), probably without >having >> read the xlogreader patch itself... > >No, I agree that global-impact things like this palloc rearrangement >are >much better proposed and debated separately than as part of something >like xlogreader. What I was reacting to was the specific patch set >associated with this thread. I don't see the point of breaking out a >two-line sub-patch such as you did in >http://archives.postgresql.org/message-id/1357730830-25999-3-git-send-email-and...@2ndquadrant.com Ah, yes. I See your point. The not all that good reasoning I had in mind was that that one should be uncontroversial as it seemed to be the only unchecked malloc call in src/bin. So it could be committed independent from the more controversial stuff... Same with the single whitespace removal patch upthread... Andres --- Please excuse brevity and formatting - I am writing this on my mobile phone. -- 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] logical changeset generation v4
Josh Berkus schrieb: >Andreas, > >Is there a git fork for logical replication somewhere? Check the bottom of the email ;) --- Please excuse brevity and formatting - I am writing this on my mobile phone. -- 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] overlapping strncpy/memcpy errors via valgrind
Tom Lane schrieb: >Andres Freund writes: >> On 2013-02-17 15:10:35 +, Greg Stark wrote: >>> Peter G is sitting near me and reminded me that this issue came up >in the >>> past. Iirc the conclusion then is that we're calling memcpy where >the >>> source and destination pointers are sometimes identical. Tom decided >there >>> was really no realistic architecture where that wouldn't work. > >> I am not so convinced that that is safe if libc turns that into some >> optimized string instructions or even PCMPSTR... > >What would you envision happening that would be bad? Afair some of the optimized instructions (like movdqa) don't necessarily work if source an target are in the same location. Not sure about it bit I wouldn't want to depend on it. Andres --- Please excuse brevity and formatting - I am writing this on my mobile phone. -- 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] overlapping strncpy/memcpy errors via valgrind
Tom Lane schrieb: >Boszormenyi Zoltan writes: >> Then, why isn't memcpy() skipped if the source and dest are the same? >> It would be a micro-optimization but a valid one. > >No, it'd be more like a micro-pessimization, because the test would be >wasted effort in the vast majority of calls. The *only* reason to do >this would be to shut up valgrind, and that seems annoying. > >I wonder if anyone's tried filing a bug against valgrind to say that it >shouldn't complain about this case. You already need a suppression file to use valgrind sensibly, its easy enough to add it there. Perhaps we should add one to the tree? --- Please excuse brevity and formatting - I am writing this on my mobile phone. -- 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] overlapping strncpy/memcpy errors via valgrind
Peter Geoghegan schrieb: >On 17 February 2013 18:52, anara...@anarazel.de >wrote: >> You already need a suppression file to use valgrind sensibly, its >easy enough to add it there. Perhaps we should add one to the tree? > >Perhaps you should take the time to submit a proper Valgrind patch >first. The current approach of applying the patch that Noah Misch >originally wrote (but did not publicly submit, iirc) on an ad-hoc >basis isn't great. That is what you've done here, right? What patch are you talking about? I have no knowledge about any pending valgrind patches except one I made upstream apply to make pg inside valgrind work on amd64. Andres --- Please excuse brevity and formatting - I am writing this on my mobile phone. -- 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] Support for REINDEX CONCURRENTLY
Hi, Michael Paquier schrieb: >Andres, Masao, do you need an extra round or review or do you think >this is >ready to be marked as committer? >On my side I have nothing more to add to the existing patches. I think they do need review before that - I won't be able to do another review before the weekend though. Andres --- Please excuse brevity and formatting - I am writing this on my mobile phone. -- 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] REFRESH MATERIALIZED VIEW locklevel
Kevin Grittner schrieb: >Andres Freund wrote: > >> if I understand things correctly REFRESH MATERIALIZED VIEW locks >> the materialized view with an AcessExclusiveLock even if the view >> already contains data. > >Yeah. At the time I had to make a decision on that, REINDEX >CONCURRENTLY did not seem reliable with a weaker lock, and REFRESH >MATERIALIZED VIEW has to rebuild indexes (among other things). If >we have all the issues sorted out with REINDEX CONCURRENTLY then >the same techniques will probably apply to RMV without too much >difficulty. It's a bit late to think about that for 9.3, though. > >> I am pretty sure that will - understandably - confuse users, so I >> vote for at least including a note about that in the docs. > >Will see about working that in. In the ride home I realized that unless - not that unlikely - you thought about something I didtn't REFRESH will behave similar to TRUNCATE for repeatable read+ transactions that only access it after REFRESH finished. That is, they will appear empty. If that's the case, it needs to be documented prominently as well. It would be possible to get different behaviour by immediately freezing all tuples, but that would also result in violations of visibility by showing tuples that are not yet visible. Andres --- Please excuse brevity and formatting - I am writing this on my mobile phone. -- 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] Ignore invalid indexes in pg_dump.
Tom Lane schrieb: >Bruce Momjian writes: >> Should I just patch pg_upgrade to remove the "indisvalid", skip >> "indisvalid" indexes, and backpatch it? Users should be using the >> version of pg_upgrade to match new pg_dump. Is there any case where >> they don't match? Do I still need to check for "indisready"? > >Yeah, if you can just ignore !indisvalid indexes that should work fine. >I see no need to look at indisready if you're doing that. You need to look at inisready in 9.2 since thats used for about to be dropped indexes. No? Andres --- Please excuse brevity and formatting - I am writing this on my mobile phone. -- 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] Ignore invalid indexes in pg_dump.
Tom Lane schrieb: >"anara...@anarazel.de" writes: >> Tom Lane schrieb: >>> Yeah, if you can just ignore !indisvalid indexes that should work >fine. >>> I see no need to look at indisready if you're doing that. > >> You need to look at inisready in 9.2 since thats used for about to be >dropped indexes. No? > >No, he doesn't need to look at indisready/indislive; if either of those >flags are off then indisvalid should certainly be off too. (If it >isn't, queries against the table are already in trouble.) 9.2 represents inisdead as live && !ready, doesn't it? So just looking at indislive will include about to be dropped or partially dropped indexes? Andres --- Please excuse brevity and formatting - I am writing this on my mobile phone. -- 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] Why are JSON extraction functions STABLE and not IMMUTABLE?
Andrew Dunstan schrieb: > >On 04/15/2013 11:46 AM, Andres Freund wrote: >>> >>> Me either. It's an oversight, really. Unless there is any objection >I'll >>> change them toot sweet. What about the existing (as of 9.2) >functions? >> ISTM json_in, out, recv, send should also be immutable. >array_to_json, >> row_to_json et all can't be tho. > > >OK, although these have been like this since 9.2. I'm not sure why >json_out is immutable but json_in isn't. > >Does changing these require a catalog version bump? Well, you could get away without one since a more permissive value should only influence performance and not correctness. But there doesn't yet seem much reason to avoid it that much yet. It could cause confusion for someone at some point. Andres --- Please excuse brevity and formatting - I am writing this on my mobile phone. -- 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] [ADMIN] Simultaneous index creates on different schemas cause deadlock?
Tom Lane schrieb: >Andres Freund writes: >> On 2013-04-25 13:17:31 -0400, Tom Lane wrote: >>> Since we know that C.I.C. executes in its own transaction, and there >>> can't be more than one on the same table due to locking, it seems to >me >>> that it'd be safe to drop our own snapshot before waiting for other >>> xacts to end. That is, we could just rearrange the last few steps >in >>> DefineIndex(), taking care to save snapshot->xmin before we destroy >the >>> snapshot so that we still have that value to pass to >>> GetCurrentVirtualXIDs(). >>> >>> Anybody see a flaw in that solution? > >> Except that it still will unnecessarily wait for other CICs, just not >> deadlock, I don't see a problem. We could have a PROC_IN_CIC flag or >> something so we can ignore other index creations, but I am not sure >if >> its worth the complication. > >I'm not sure it's a good idea to ignore other CICs altogether --- they >could be executing user-defined index functions that do strange things >like consult other tables. Since this seems to me to be a bit outside >the intended use-case for CIC anyway, I think it's good enough if they >just don't deadlock Fine with me, especially as nobody seems to have complained so far other than the OP, so it doesn't seem to be to common. I don't have access to the code ATM an I wonder whether DROP CONCURRENTLY has a similar problem? Depends a bit on how the waiting is done... Andres --- Please excuse brevity and formatting - I am writing this on my mobile phone. -- 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] Proof of concept: standalone backend with full FE/BE protocol
Tom Lane schrieb: >Andres Freund writes: >> I don't find that a convincing comparison. Normally don't need to >shutdown the >> server between two pg_dump commands. Which very well might be >scripted. > >> Especially as for now, without a background writer/checkpointer >writing stuff >> beforehand, the shutdown checkpoint won't be fast. IO isn't unlikely >if youre >> doing a pg_dump because of hint bits... > >I still think this is a straw-man argument. There is no expectation >that a standalone PG implementation would provide performance for a >series of standalone sessions that is equivalent to what you'd get from >a persistent server. If that scenario is what's important to you, >you'd >use a persistent server. The case where this sort of thing would be >interesting is where minimizing administration complexity (by not >having >a server) is more important than performance. People currently use, >eg, >SQLite for that type of application, and it's not because of >performance. I am not saying its bad that it is slower, that's absolutely OK. Just that it will take a variable amount of time till you can run pgdump again and its not easily detectable without looping and trying again. Andres --- Please excuse the brevity and formatting - I am writing this on my mobile phone. -- 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 8/8] Introduce wal decoding via catalog timetravel
Bruce Momjian schrieb: >On Thu, Oct 11, 2012 at 12:02:26AM +0100, Peter Geoghegan wrote: >> On 15 September 2012 01:39, Andres Freund >wrote: >> > (0008-Introduce-wal-decoding-via-catalog-timetravel.patch) >> >> This patch is the 8th of 8 in a patch series that covers different >> aspects of the bi-directional replication feature planned for >> PostgreSQL 9.3. For those that are unfamiliar with the BDR >projection, >> a useful summary is available in an e-mail sent to this list by Simon >> Riggs back in April [1]. I should also point out that Andres has made > >Does this design allow replication/communcation between clusters >running >different major versions of Postgres? This patchset only contains only the decoding/changeset generation part of logical replication. It provides (as in the debugging example) the capabilities to generate a correct textual format and thus can be used to build a solution with support for cross version/arch replication as long as the text format of the used types is compatible. Does that answer the question? Andres --- Please excuse the brevity and formatting - I am writing this on my mobile phone. -- 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] libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable
Alex Goncharov schrieb: >,--- You/Andres (Fri, 7 Oct 2011 02:28:30 +0200) * >| > a lot of cases where the database could deduce (quite easily) that >a >| > result column cannot be null >| Could you quickly explain what exactly you want that information for? >Just >| because it has been done before doesn't necessarily mean its a good >idea... > >I am not writing a database application here (i.e. I am not storing >the data). I am responding to a client requirement, basically: > > Given a SELECT (or possibly, simpler, a table name), tell me which > columns are non-nullable? That doesnt explain why it's needed. To get community buyin into a feature the community - or at least parts of it - need to understand why its needed. Greetings, Andres -- 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] testing ProcArrayLock patches
Kevin Grittner schrieb: >Robert Haas wrote: > >> Any chance you can run oprofile (on either branch, don't really >> care) against the 32 client test and post the results? > >Besides the other changes we discussed, I boosted scale to 150 and >ran at READ COMMITTED isolation level (because all threads promptly >crashed and burned at REPEATABLE READ -- we desperately need a >pgbench option to retry a transaction on serialization failure). >The oprofile hot spots at half a percent or higher: > >CPU: Intel Core/i7, speed 2262 MHz (estimated) >Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with >a unit mask of 0x00 (No unit mask) count 10 >samples %image name symbol name >9333944.9651 postgresAllocSetAlloc >8484764.5134 postgresbase_yyparse >7195153.8274 postgresSearchCatCache >4612752.4537 postgreshash_search_with_hash_value >4264112.2682 postgresGetSnapshotData >3229381.7178 postgresLWLockAcquire >3222361.7141 postgrescore_yylex >3054711.6249 postgresMemoryContextAllocZeroAligned >2815431.4976 postgresexpression_tree_walker >2702411.4375 postgresXLogInsert >2348991.2495 postgresMemoryContextAlloc >2101371.1178 postgresScanKeywordLookup >1848570.9833 postgresheap_page_prune >1736080.9235 postgreshash_any >1530110.8139 postgres_bt_compare >1445380.7689 postgresnocachegetattr >1314660.6993 postgresfmgr_info_cxt_security >1310010.6968 postgresgrouping_planner >1308080.6958 postgresLWLockRelease >1241120.6602 postgresPinBuffer >1207450.6423 postgresLockAcquireExtended >1129920.6010 postgresExecInitExpr >1128300.6002 postgreslappend >1123110.5974 postgresnew_list >1103680.5871 postgrescheck_stack_depth >1060360.5640 postgresAllocSetFree >1025650.5456 postgresMemoryContextAllocZero >94689 0.5037 postgresSearchSysCache That profile looks like you ran pgbench with -m simple. How does it look with prepared instead? Andres >-- >Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) >To make changes to your subscription: >http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
