Re: [HACKERS] Our trial to TPC-DS but optimizer made unreasonable plan

On Thu, Aug 27, 2015 at 1:01 PM, Qingqing Zhou <zhouqq.postg...@gmail.com> wrote: > On Wed, Aug 26, 2015 at 5:28 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> After looking at the code a bit, IMO the most reasonable thing to do is to >

Re: [HACKERS] Horizontal scalability/sharding

On Mon, Aug 31, 2015 at 2:12 AM, Oleg Bartunov wrote: > > AFAIK, XC/XL has already some customers and that is an additional pressure > on their development team, which is now called X2. I don't exactly know how > internal Huawei's MPPDB is connected to XC/XL. > Huawei's

Re: [HACKERS] Our trial to TPC-DS but optimizer made unreasonable plan

On Wed, Aug 26, 2015 at 5:28 PM, Tom Lane t...@sss.pgh.pa.us wrote: After looking at the code a bit, IMO the most reasonable thing to do is to include this transformation in inline_set_returning_functions(), perhaps renaming it to something like inline_srfs_and_ctes(). This is essentially

Re: [HACKERS] Our trial to TPC-DS but optimizer made unreasonable plan

On Wed, Aug 19, 2015 at 10:32 AM, Qingqing Zhou zhouqq.postg...@gmail.com wrote: On Tue, Aug 18, 2015 at 5:59 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote: BTW, did you register the patch on the upcoming commit-fest? Not yet, it is in WIP status. While I am working on the patch, I found some

Re: [HACKERS] CTE optimization fence on the todo list?

On Fri, May 1, 2015 at 2:39 PM, Tom Lane t...@sss.pgh.pa.us wrote: * Multiply-referenced WITH item (unless the outer query applies identical constraints to each reference, which seems silly and not worth the cycles to check for). Not sure if I understand this correctly. Look at this query, CTE

Re: [HACKERS] Our trial to TPC-DS but optimizer made unreasonable plan

On Tue, Aug 18, 2015 at 5:59 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote: BTW, did you register the patch on the upcoming commit-fest? Not yet, it is in WIP status. I think it may be a helpful feature, if we can add alternative subquery-path towards cte-scan on set_cte_pathlist() and choose

Re: [HACKERS] Our trial to TPC-DS but optimizer made unreasonable plan

On Mon, Aug 17, 2015 at 6:40 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote: Here is one other thing I could learn from TPC-DS benchmark. The attached query is Q4 of TPC-DS, and its result was towards SF=100. It took long time to compete (about 30min), please see the attached EXPLAIN ANALYZE

Re: [HACKERS] fix oversight converting buf_id to Buffer

All look good to me, Thank you, Qingqing On Wed, Aug 12, 2015 at 8:37 AM, Andres Freund and...@anarazel.de wrote: Hi, On 2015-08-11 01:15:37 +0200, Andres Freund wrote: I'm too tired right now to look at this, but it generally looked sane. Pushed your fix to master and 9.5, with two very

Re: [HACKERS] cache invalidation skip logic

On Sun, Aug 9, 2015 at 8:24 AM, Robert Haas robertmh...@gmail.com wrote: In step 1, AcceptInvalidationMessages() should process all pending invalidation messages. So if step 2 did AcceptInvalidationMessages() again it would be a no-op, because no messages should remain at that point.

[HACKERS] fix oversight converting buf_id to Buffer

Attached patch fixes oversights converting buf_id to Buffer in PrintBufferDescs() and InvalidateBuffer(). Especially for the latter, the reason we haven't seen any reports of the issue might be that it needs certain concurrent conditions to be true. Along the line, it also changes all direct

Re: [HACKERS] fix oversight converting buf_id to Buffer

On Mon, Aug 10, 2015 at 4:15 PM, Andres Freund and...@anarazel.de wrote: That's a very nice catch! Did you trigger the error or just found it when reading the code? My fellow colleagues hit the issue during some stress: I am not clear the exact repro but from the failed assertion, the cause

[HACKERS] cache invalidation skip logic

In cache invalidation logic, we have the following comment: /* * Now that we have the lock, check for invalidation messages, so that we * will update or flush any stale relcache entry before we try to use it. * RangeVarGetRelid() specifically relies on us for this. We can skip * this in the

Re: [HACKERS] Planner debug views

On Thu, Jul 30, 2015 at 2:42 PM, Jim Nasby jim.na...@bluetreble.com wrote: I think a better option would be shoving it into a backend tuplestore and just leaving it there (maybe with a command to clear it for the paranoid). That gives a relation you can query against, insert into another

Re: [HACKERS] Division by zero in planner.c:grouping_planner()

On Wed, Jul 29, 2015 at 11:26 AM, Piotr Stefaniak postg...@piotr-stefaniak.me wrote: + Assert(path_rows != 0); if (tuple_fraction = 1.0) tuple_fraction /= path_rows; } This does not sounds right:

Re: [HACKERS] Planner debug views

On Tue, Jul 28, 2015 at 6:13 PM, Tom Lane t...@sss.pgh.pa.us wrote: Another point is that we decided a long time ago that EXPLAIN's plain-text output format is not intended to be machine-parsable, and so objecting to a design on the grounds that it makes machine parsing harder is pretty

Re: [HACKERS] Planner debug views

On Tue, Jul 28, 2015 at 2:43 PM, Tom Lane t...@sss.pgh.pa.us wrote: You can do something like that in plpgsql, for example declare t text; for t in EXPLAIN SELECT ... loop insert into whatever values(t); end loop; I see - this is cool. There are still something

Re: [HACKERS] Planner debug views

On Mon, Jul 27, 2015 at 8:20 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: I think this is a pretty neat idea, but I'm not sure this user interface is a good one. Why not have a new option for EXPLAIN, so you would call EXPLAIN (planner_stuff=on) and it returns this as a resultset?

Re: [HACKERS] Planner debug views

On Tue, Jul 28, 2015 at 12:08 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: I would have a tuplestore, and the planner code would push tuples to it. After the planning is done, EXPLAIN can read and return tuples from the store to the user. Not sure if I got it: so EXPLAIN will return

Re: [HACKERS] Planner debug views

On Thu, Jul 23, 2015 at 4:11 PM, Tatsuo Ishii is...@postgresql.org wrote: Sounds like a great feature! Thanks! Attached is a draft patch implementing the idea. To play with it, you shall create the follow two foreign tables: CREATE EXTENSION file_fdw; CREATE SERVER pglog FOREIGN DATA WRAPPER

Re: [HACKERS] Planner debug views

On Tue, Jul 21, 2015 at 5:15 PM, Qingqing Zhou zhouqq.postg...@gmail.com wrote: Here is a proposal introducing some debugging infrastructure into the core. The basic idea is to allow us to query the planner search space. To so do, we can dump related information to csv files and use foreign

[HACKERS] Planner debug views

Here is a proposal introducing some debugging infrastructure into the core. The basic idea is to allow us to query the planner search space. To so do, we can dump related information to csv files and use foreign table to query them. So here I propose two foreign tables: create foreign table

Re: [HACKERS] Memory Accounting v11

On Thu, Jul 2, 2015 at 11:37 AM, CK Tan ck...@vitessedata.com wrote: I am sorry to ask questions unrelated to the subject, but how is tracking memory going to fix the HashAgg blow up problem? Is there a plan to make HashAgg not blow up (i.e. spill the hash table)? Your question is probably

Re: [HACKERS] Is it possible to have a fast-write Index?

On Fri, Jun 5, 2015 at 10:59 AM, Tom Lane t...@sss.pgh.pa.us wrote: So I really doubt that anyone would have any enthusiasm for saddling btree with a similar mechanism. It's complicated (and has been the cause of multiple bugs); it's hard to figure out when is the optimal time to flush the

Re: [HACKERS] Use outerPlanState() consistently in executor code

On Mon, May 4, 2015 at 1:23 PM, Robert Haas robertmh...@gmail.com wrote: I fixed several whitespace errors, reverted the permissions changes you included Sorry about the permission changes - didn't notice that bite. Thanks, Qingqing -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Use outerPlanState() consistently in executor code

On Thu, Apr 30, 2015 at 5:04 PM, Tom Lane t...@sss.pgh.pa.us wrote: I think I'd have done many of these as + PlanState *outerPlan = outerPlanState(node); rather than finding assorted random places to initialize the variables. Agreed. Attached patch is revision along this line.

Re: [HACKERS] Use outerPlanState() consistently in executor code

On Thu, Apr 30, 2015 at 8:02 AM, Robert Haas robertmh...@gmail.com wrote: I don't mind the MSDOS newlines, but the UTF-16le bit is inconvenient. UTF-8 would be much better, so I don't have to figure out how to convert. The patch is generated via github windows tool and that's possibly why. I

Re: [HACKERS] Relation extension scalability

On Fri, Apr 17, 2015 at 11:19 AM, Qingqing Zhou zhouqq.postg...@gmail.com wrote: Most commercial database employs a DMS storage model, where it manages object mapping and freespace itself. So different objects are sharing storage within several files. Surely it has historic reasons

Re: [HACKERS] optimizing vacuum truncation scans

On Sun, Apr 19, 2015 at 7:09 PM, Jeff Janes jeff.ja...@gmail.com wrote: I did literally the simplest thing I could think of as a proof of concept patch, to see if it would actually fix things. I just jumped back a certain number of blocks occasionally and prefetched them forward, then

Re: [HACKERS] [PERFORM] pushing order by + limit to union subqueries

On Sat, Feb 28, 2015 at 8:24 AM, Tom Lane t...@sss.pgh.pa.us wrote: There would be cases where that would be a win, and there would be cases where it wouldn't be, so I'd not be in favor of making the transformation blindly. Unfortunately, given the current state of the planner that's all we

[HACKERS] Assert there is no duplicated exit callbacks

Attached is a patch to assert there is no duplicated exit callbacks. Along the way, I downgrade the runtime enough room check to an assertion: the callbacks are registered in pretty fixed initialization code path, thus assertion is good enough to prevent overlook there. If we don't agree with

Re: [HACKERS] Assert there is no duplicated exit callbacks

Hmm, the email text seems corrupted? Regards, Qingqing On Wed, Apr 15, 2015 at 10:03 AM, Heikki Linnakangas hlinn...@iki.fi wrote: 湏〠⼴㔱㈯㄰‵㜰㔺′䵐‬楑杮楱杮娠潨⁵牷瑯㩥਍‾瑁慴档摥椠⁳⁡慰捴⁨潴愠獳牥⁴ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] reparsing query

On Wed, Apr 15, 2015 at 1:40 PM, Andrzej Barszcz abus...@gmail.com wrote: I knock once again with this : reparse query to XML ( last knock 5-6 years before) . What exactly reparse query to XML does? Regards, Qingqing -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

[HACKERS] Use outerPlanState() consistently in executor code

In executor context, outerPlanState(node) is the same as node-ss.ps.lefttree. We follow this in most places except a few. This patch clean up the outliers and might save us a few instructions by removing indirection. Most of changes are trivial. Except I take out an outerPlan nullable check in

Re: [HACKERS] reparsing query

On Wed, Apr 15, 2015 at 2:04 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: His old posting: https://www.postgresql.org/message-id/1247323023.16438.35.camel%40ab-desktop Is this a proposal to have a better formatted (JSON etc) debug_print_parse results? Thanks, Qingqing -- Sent via

Re: [HACKERS] reparsing query

On Wed, Apr 15, 2015 at 5:19 PM, Lukas Fittl lu...@fittl.com wrote: It'd be interesting to explore if there is some way to make this less hack-ish, and enable tools to parse queries in a better way. Essentially what is needed is some way to reliably translate SQL into an AST-like output, from

[HACKERS] rare avl shutdown slowness (related to signal handling)

I am playing git tip on windows 7/32 bits, with the backend compiled with visual studio 2005 (I know, it is very old :-( ). I encountered avl shutdown slowness twice, last night and this morning: after a ctrl_c is hit, wait for another 60 seconds, server shuts down. Here is one log:

Re: [HACKERS] rare avl shutdown slowness (related to signal handling)

as there is way to go back. So we can insert HOLD_INTERRUPTS() just before it. Thoughts? Regards, Qingqing On Tue, Apr 7, 2015 at 10:54 AM, Qingqing Zhou zhouqq.postg...@gmail.com wrote: I am playing git tip on windows 7/32 bits, with the backend compiled with visual studio 2005 (I know

Re: [HACKERS] rare avl shutdown slowness (related to signal handling)

On Tue, Apr 7, 2015 at 2:32 PM, Tom Lane t...@sss.pgh.pa.us wrote: That seems like (a) a hack, and (b) not likely to solve the problem completely, unless you leave interrupts held throughout proc_exit(), which would create all sorts of opportunities for corner case bugs during on_proc_exit

Re: [HACKERS] rare avl shutdown slowness (related to signal handling)

On Tue, Apr 7, 2015 at 4:01 PM, Tom Lane t...@sss.pgh.pa.us wrote: Indeed, which is why I think a patch for this issue should not introduce a new mode/context in which proc_exit() is executed. Agree. Along this line, we can add an on_proc_exit hook simply ereport(we are exiting) there. In this

Re: [HACKERS] Tuple visibility within a single XID

On Tue, Apr 7, 2015 at 6:11 PM, Peter Geoghegan p...@heroku.com wrote: No. For one thing, unique index enforcement still requires the tuples to be treated as a conflict while the other transaction is running IMV. Not sure if I understand correctly: in uniqueness check, we see all possible

[HACKERS] COALESCE() query yield different result with MJ vs. NLJ/HJ

The symptom is that the same join query yield different results with MJ and NLJ/HJ. Here is a repro: --- create table t1(a int);create table t2(b int); insert into t1 values(10); insert into t2 values(2); analyze t1; analyze t2; set enable_mergejoin=on; set enable_nestloop=off; set

Re: [HACKERS] 32bit OID wrap around concerns

On Mon, Mar 2, 2015 at 12:38 PM, Tom Lane t...@sss.pgh.pa.us wrote: There is an issue if you do a dump and restore: the toast OIDs used in any one table will be consecutive after that, because we load all the data for each table sequentially. With these consecutive oids, the aggravated oid

[HACKERS] 32bit OID wrap around concerns

One scenario is to use an oid to identify a toast value. As the oid generation is mono increased within a database instance, it can gets wrap around after 2^32 generations. After that: 1. GetNewOidWithIndex() could gets unbounded performance as it needs to by pass already in use values of its own.

[HACKERS] Question on SIGFPE in Windows

SIGFPE is a synchornous signal and Windows will raise it if proper flag is set (check out the example program): http://msdn2.microsoft.com/en-us/library/kfy34skx.aspx But seems we didn't use the above method. Instead, we use the same methodology as other asynchrounous signals. My question

Re: [HACKERS] default lower case of identifier

jkzhao [EMAIL PROTECTED] wrote But, create user HU then connect PostgreSQL by HU is wrong. If you do postgres=# create user HU; You will get the HU as you want. Usage of the quotation marks is in the manual. I'd like to know whether I can make PostgreSQL stands to the SQL92

[HACKERS] ShmemAlloc() alignment patch

In ShmemAlloc() we have: newStart = BUFFERALIGN(newStart); newSpace = (void *) (ShmemBase + newStart); return newSpace; Notice that though newStart is ALIGNOF_BUFFER, ShmemBase is not. Thus the newSpace is not aligned as we disired. Attached please find the patch. Regards, Qingqing

Re: [HACKERS] postgresql.conf basic analysis tool

Andrew Hammond [EMAIL PROTECTED] wrote Also, are there any other (simple for now) things I should look at in the process? The shared memory estimiation logic is in ipc/ipci.c/CreateSharedMemoryAndSemaphores(). If you want to get an accurate number, you need to consider: (1) different

Re: [HACKERS] poor performance with Context Switch Storm at TPC-W.

Katsuhiko Okano [EMAIL PROTECTED] wrote The problem has occurred in my customer. poor performance with Context Switch Storm occurred with the following composition. Usually, CS is about 5000, WIPS=360. when CSStorm occurrence, CS is about 10, WIPS=60 or less. Intel Xeon 3.0GHz*4(2CPU

[HACKERS] Small overhead run time memory trace (Was Re: shall we have a TRACE_MEMORY mode)

Tom Lane [EMAIL PROTECTED] wrote One idea that comes to mind is to have a compile time option to record the palloc __FILE__ and _LINE__ in every AllocChunk header. Then it would not be so hard to identify the culprit while trawling through memory. The overhead costs would be so high that

[HACKERS] Problem to current-status information in shared memory patch

On CVS tip: $ postgres --single -Ddata postgres PostgreSQL stand-alone backend 8.2devel Segmentation fault (core dumped) $ gdb -c core.18119 (gdb) bt #0 pgstat_report_activity (cmd_str=0x67d25e IDLE) at pgstat.c:1484 1484beentry-st_changecount++; (gdb) bt #0 pgstat_report_activity

Re: [HACKERS] Problem to current-status information in shared memory patch

Tom Lane [EMAIL PROTECTED] wrote postgres --single works for me. Maybe you need a make distclean/rebuild? Sorry, because I forget to say that you need to turn stats_command_string on. When it is off, pgstat_report_activity() will return immediately so nothing wrong could be observed.

Re: [HACKERS] shall we have a TRACE_MEMORY mode

Alvaro Herrera [EMAIL PROTECTED] wrote But the problem (or at last a part of the problem) is not what context each chunk is allocated in, but where did a given chunk come from (where was it allocated), Which is why saving __FILE__/__LINE__ is useful. Agreed. Maybe we should not clutter

Re: [HACKERS] sync_file_range()

ITAGAKI Takahiro [EMAIL PROTECTED] wrote I'm interested in it, with which we could improve responsiveness during checkpoints. Though it is Linux specific system call, but we could use the combination of mmap() and msync() instead of it; I mean we can use mmap only to flush dirty pages, not

[HACKERS] shall we have a TRACE_MEMORY mode

As I follow Relyea Mike's recent post of possible memory leak, I think that we are lack of a good way of identifing memory usage. Maybe we should also remember __FILE__, __LINE__ etc for better memory usage diagnose when TRACE_MEMORY is on? Regards, Qingqing ---(end of

[HACKERS] kill_prior_tuple for bitmap scan

As I read, the kill_prior_tuple optimization doesn't work for bitmap scan code. To fix this problem, we have two choices. One is still use the kill_prior_tuple trick in a modified way. Heap TIDs recycling should not be a problem. This is because generally we always hold pin of the last index page

Re: [HACKERS] kill_prior_tuple for bitmap scan

Tom Lane [EMAIL PROTECTED] wrote Really? An indexscan will release pin before returning no-more-tuples, and had better do so else we leak pins during queries involving many indexscans. I guess I see your point. For the scan stages not returning no-more-tuples, we can do kill, but the

Re: [HACKERS] Test request for Stats collector performance improvement

Bruce Momjian pgman@candle.pha.pa.us wrote Would some people please run the attached test procedure and report back the results? I basically need to know the patch is an improvement on more platforms than just my own. Thanks Obviously it matches your expectation. uname: Linux amd64

Re: [HACKERS] Are we still interested in the master-slave scan patch

Josh Berkus josh@agliodbs.com wrote The other is the connection pool architecture: shall we let postmaster manage the slaves or let another process say slave-master to handle them? Currently I am choosing the latter. Hmmm. Why not the postmaster? Not real reason just feel that's

Re: [HACKERS] Remove the limit on the number of entries allowed in catcaches,

Simon Riggs [EMAIL PROTECTED] wrote Can we do the same for the file descriptors in fd.c? Very often the total number of file descriptors is much less than the maximum, so it would make sense to only maintain the LRU when we are using more than 50%-75% of the maximum. I am not against

Re: [HACKERS] Test request for Stats collector performance improvement

Tom Lane [EMAIL PROTECTED] wrote Hm? I don't see any improvement there: I was referening this sentence, though I am not sure why that's the expectation: Bruce Momjian pgman@candle.pha.pa.us wrote If the patch worked, the first and third times will be similar, and the second time will be

[HACKERS] What can we improve if we have a battery-backed-disk?

When I read the post related to the battery-backed disks, I come to this question: What can we improve/reduce if we have them? Since our fsync methods is already be able support that (thought not automatically), we may want to look into other parts. One issue is the xlog and our aim is (1) reduce

Re: [HACKERS] Tuple hint bits (INFOMASK) upon transaction abort

letizia leo [EMAIL PROTECTED] wrote Transaction T1 updates a given tuple -- xmax is set to T1 on that tuple ... later on, T1 aborts... we believe that in this circumstance HEAP_XMAX_INVALID should be set on the tuple to signal that the tuple was not actually deleted by T1 since this

Re: [HACKERS] Test request for Stats collector performance improvement

Bruce Momjian pgman@candle.pha.pa.us wrote -- After patch -- real0m1.275s user0m0.097s sys 0m0.160s real0m4.063s user0m0.663s sys 0m0.377s real0m1.259s user0m0.073s sys 0m0.160s I assume the above is just running the same test three

Re: [HACKERS] Test request for Stats collector performance improvement

Bruce Momjian pgman@candle.pha.pa.us wrote Any idea why there is such a variance in the result? The second run looks quite slow. No luck so far. It is quite repeatble in my machine -- runing times which show a long execution time: 2, 11, 14, 21 ... But when I do strace, the weiredness

Re: [HACKERS] Spinlocks, yet again: analysis and proposed patches

Bruce Momjian pgman@candle.pha.pa.us wrote Added to TODO list. One thing we tried in February was padding out the statically defined locks with dummy lock definitions in the enum. This has the effect of ensuring that the most contested locks are very definitely in their own cache line

Re: [HACKERS] Spinlocks, yet again: analysis and proposed patches

Tom Lane [EMAIL PROTECTED] wrote Not really --- that patch was intended to ensure that LWLocks don't unnecessarily cross two cache lines. It doesn't ensure that two different LWLocks aren't sharing a cache line. You could do that by increasing LWLOCK_PADDED_SIZE to the cache line size for

[HACKERS] Are we still interested in the master-slave scan patch

I may have some free time recently to work on the master-slave scan idea. I've been able to support AS-IS both SeqScan and IndexScan. Are we still interested in getting it into 8.2? There are still some problems I am not quite sure the solution. One is the Xid assignment -- we need this to assure

Re: [HACKERS] code cleanup for SearchSysCache

Tom Lane [EMAIL PROTECTED] wrote You'd need two essentially equivalent versions of SearchSysCache, and you'd lose the ability to make the error message identify what was being searched for, so I vote no. Both arguments are not necessarily true. This change is quite like what we made to

[HACKERS] self-deadlock at FATAL exit of boostrap process on read error

I encounter a situation that the server can't shutdown when a boostrap process does ReadBuffer() but gets an read error. I guess the problem may be like this - the boostrap process can't read at line: smgrread(reln-rd_smgr, blockNum, (char *) bufBlock); So it does a FATAL exit and

Re: [HACKERS] self-deadlock at FATAL exit of boostrap process on read error

Tom Lane [EMAIL PROTECTED] wrote Do you have a test case to reproduce this problem? According to the error message, the problem happens during reading pg_database. I just tried to plug in this line in mdread(): +/* pretend there is an error reading pg_database */ +if

[HACKERS] code cleanup for SearchSysCache

There are roughly 420 calls of SearchSysCache() and 217 of which are just report cache lookup failed. Shall we put the elog in the SearchSysCache itself? Notice that most search is on the Oid field -- which is *not* user visible, so I think most of them can safely let SearchSysCache handle the

Re: [HACKERS] bgwriter statistics

Jim Nasby [EMAIL PROTECTED] wrote Now that we've got a nice amount of tuneability in the bgwriter, it would be nice if we had as much insight into how it's actually doing. I'd like to propose that the following info be added to the stats framework to assist in tuning it: In general, I

Re: [HACKERS] LIKE, leading percent, bind parameters and indexes

Tom Lane [EMAIL PROTECTED] wrote Yeah. The LIKE index optimization depends on seeing a constant LIKE pattern at plan time --- otherwise the planner doesn't know what indexscan parameters to generate. So a bound-parameter query loses. AFAICS the problem is not restricted to LIKE, we can

Re: [HACKERS] psql feature thought

Joshua D. Drake [EMAIL PROTECTED] wrote What if single line statements that were seperated by ; within psql were implicitly within a transaction? E.g; postgres=# select * from foo; update foo set bar = 'baz'; delete from bing; Would be a single transaction ? The begin/commit would be

Re: [HACKERS] Why use !=

ipig [EMAIL PROTECTED] wrote in postgresql-8.1.3/src/backend/storage/lmgr/proc.c there are 2 function InitProcess and InitDummyProcess, both use if (MyProc != NULL) elog(ERROR, you already exist); (line 215 and 315) why use != ? I guess you misread exist to exit? Try

Re: [HACKERS] EXPLAIN verbose?

Cristiano Duarte [EMAIL PROTECTED] wrote Does anyone know how to discover the tables (with schemas or oid) involved on a select statement? I tried EXPLAIN but it only reports the table names, not schemas or oid. In general, this is a pretty difficult problem - thinking you may do a

Re: [HACKERS] Need some clarification

Dhanaraj M [EMAIL PROTECTED] wrote 2. *Invalidate prepared queries, like INSERT, when the table definition is altered *Invalidation means recompilation or deletion of the prepared stmt here.* *Both the items look similar. i.e) needs recompilation of the query after altering the table.

Re: [HACKERS] Further reduction of bufmgr lock contention

Tom Lane [EMAIL PROTECTED] wrote The thing that's nagging at me at the moment is the realization that a partitioned hashtable will eat more shared memory than a single hashtable. It wasn't that long ago that we had to do some hacking to ensure that the buffer hashtable couldn't run out of

Re: [HACKERS] Unresolved Win32 bug reports

Jim C. Nasby [EMAIL PROTECTED] wrote There a patched build available for testing? (I'd rather not have to figure out how to get windows builds working, unless there's some kind of instructions somewhere...) -- Not yet - the patch is still pending. Regards, Qingqing

Re: [HACKERS] Unresolved Win32 bug reports

Tom Lane [EMAIL PROTECTED] wrote Martijn van Oosterhout kleptog@svana.org writes: On Thu, Apr 20, 2006 at 12:17:07PM -0500, Jim C. Nasby wrote: Here's one to add to the list: running pgbench with a moderately heavy load on an SMP box likes to trigger a state where the database (or

Re: [HACKERS] Question on win32 semaphore simulation

Magnus Hagander [EMAIL PROTECTED] wrote I'm not sure why the win32 port chose to emulate the SysV semaphore interface anyway. You could equally well have used the Posix interface (src/backend/port/posix_sema.c). Or, given Microsoft's NIH tendencies, you might have needed to write a

Re: [HACKERS] Question on win32 semaphore simulation

Qingqing Zhou [EMAIL PROTECTED] wrote So we might want to fix current win32/sema.c for two problems: (1) semctl(SETVAL, val=0) - there is no other val than zero is used; (2) concurrent access to sem_counts[]; Attached is a patch for the above proposed change -- but still, I hope we don't

Re: [HACKERS] Question on win32 semaphore simulation

Qingqing Zhou [EMAIL PROTECTED] wrote As I reviewed the win32/sema.c, there is some code that I am not clear, can anybody explain please? There is another problem related to concurrent operations on win32 sema. Say two processes are doing semop(+1) concurrently. Look at this code: /* Don't

Re: [HACKERS] Possible race in UnlockBuffers() and UnpinBuffer()

Tom Lane [EMAIL PROTECTED] wrote Qingqing Zhou [EMAIL PROTECTED] writes: After this, the proc-sem will be bumped to 1 unexpectedly ... Since this problem is rare, a possible fix is to put a critical section around line 1 to 7 and remove UnlockBuffers() accordingly. No, that would make

[HACKERS] Possible race in UnlockBuffers() and UnpinBuffer()

We have a wait-pin-to-1 mechanism in LockBufferForCleanup() like this: 1: bufHdr-wait_backend_pid = MyProcPid; 2: bufHdr-flags |= BM_PIN_COUNT_WAITER; 3: PinCountWaitBuf = bufHdr; 4: UnlockBufHdr_NoHoldoff(bufHdr); 5: LockBuffer(buffer, BUFFER_LOCK_UNLOCK); 6: /*

[HACKERS] Question on win32 semaphore simulation

As I reviewed the win32/sema.c, there is some code that I am not clear, can anybody explain please? In semctl(SETVAL): if (semun.val sem_counts[semNum]) sops.sem_op = -1; else sops.sem_op = 1; /* Quickly lock/unlock the semaphore (if we can) */ if (semop(semId, sops, 1) 0)

Re: [HACKERS] Support Parallel Query Execution in Executor

Markus Schiltknecht [EMAIL PROTECTED] wrote Hi, On Sun, 2006-04-09 at 15:11 -0400, Tom Lane wrote: You can't just retarget a backend to operate in another database, at least not without major changes in that infrastructure. Why not? What would be needed to retarget a backend to operate

Re: [HACKERS] Updating OID column

Peter Eisentraut [EMAIL PROTECTED] wrote Is there a reason for why you can't update the OID column other than that no one has bothered to code up the support for it? AFAIK if two rows are with the same OID, we will think these two rows are different versions of the same tuple. So if we allow

Re: [HACKERS] Support Parallel Query Execution in Executor

Markus Schiltknecht [EMAIL PROTECTED] wrote Hi Qingqing, As Tom pointed out, without big change, a backend on database D1 can't connect to D2. This is because to connect to a database, we need to initialize a lot of variables. So when you reconnect to another one on the fly, you have

Re: [HACKERS] Support Parallel Query Execution in Executor

Tom Lane [EMAIL PROTECTED] wrote This is exactly the bit of optimism I was questioning. We've already been sweating blood trying to reduce multiprocessor contention on data structures in which collisions ought to be avoidable (ie, buffer arrays where you hope not everyone is hitting the

[HACKERS] WIP: master-slave seqscan patch

Upon several requests of the master-slave patch source code, I sent it here. This is a proof-of-concept implementation only to show it is feasible only. To play with it, applied it to cvs tip. When you key in a SQL like: SELECT max(i) FROM t; // t with more than 20 records You are

[HACKERS] Support Parallel Query Execution in Executor

I have written some experimental code of doing master-slave seqscan in PostgreSQL. During the work, I feel we had enough infrastructure to support parallel query execution. What I did is adding a new node PARA and plug it above the node that we want to execute in parallel. In this stage, a PARA

Re: [HACKERS] Support Parallel Query Execution in Executor

Jonah H. Harris [EMAIL PROTECTED] wrote Great work! I had looked into this a little bit and came to the same ideas/problems you did, but none of them seemed insurmountable at all. I'd be interested in working with you on this if you'd like. Yes, I am happy to work with anyone on the

Re: [HACKERS] Summer of Code Preparation

Josh Berkus josh@agliodbs.com wrote Sure, although the important part is to find students. I'm not sure how we do that. I noticed two email domains are @mit.edu and @cs.toronto.edu but I am afraid both of them are not students any more :-) Regards, Qingqing

Re: [HACKERS] Stats collection on Windows

Tom Lane [EMAIL PROTECTED] wrote The problem is that process IDs on Windows seem to be assigned without much rhyme or reason and it seems to happen relatively frequently that a new process will be assigned the same process ID as a process which recently died. That's an interesting theory,

Re: [HACKERS] Stats collection on Windows

Tom Lane [EMAIL PROTECTED] wrote Redmond crowd should be able to figure out that recycling process IDs instantly would be a stupid idea...) Can you explain more of this? IMHO, if we rely on feature like this, the difference is unstable-every-day vs. unstable-every-year. Regards, Qingqing

Re: [HACKERS] Problem compiling with mingw

Juan Manuel Diaz Lara [EMAIL PROTECTED] wrote bootparse.y:101:10: b4_file_name is not a valid filename bison-2.1.exe -- d:\gnuwin32 Maybe it is bison's problem. I always use 1.875 since it has been there long enough powerful enough ... Regards, Qingqing ---(end

Re: [HACKERS] [GENERAL] PANIC: heap_update_redo: no block

Qingqing Zhou [EMAIL PROTECTED] wrote Tom Lane [EMAIL PROTECTED] wrote What we should be seeing, and don't see, is an indication of a backup block attached to this WAL record. Furthermore, I don't see any indication of a backup block attached to *any* of the WAL records in Alex's printout

Re: [HACKERS] WAL dirty-buffer management bug

Tom Lane [EMAIL PROTECTED] wrote This is pretty much what heapam and btree currently do, but on looking at it I think it's got a problem: we really ought to mark the buffer dirty before releasing the critical section. Otherwise, if there's an elog(ERROR) before the WriteBuffer call is

Re: [HACKERS] pg_class catalog question...

Jonah H. Harris [EMAIL PROTECTED] wrote Yeah, I noticed that one. How would you suggest setting CLASS_TUPLE_SIZE in that case? What if you put your char[64] before relhassubclass, then you don't change CLASS_TUPLE_SIZE. Regards, Qingqing ---(end of

  1   2   3   4   >