Обсуждение: contrib/pg_buffercache
... is apparently broken for Windows and Cygwin. See for example http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=loris&dt=2005-03-16%2001:55:33 cheers andrew
Andrew Dunstan wrote: > ... is apparently broken for Windows and Cygwin. See for example > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=loris&dt=2005-03-16%2001:55:33 > cheers hmmm - never tried to compile it on win32! I am getting http 502 from the above url, so I will have a go at building on win32 tomorrow. cheers Mark
Andrew Dunstan wrote: > ... is apparently broken for Windows and Cygwin. See for example > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=loris&dt=2005-03-16%2001:55:33 > Andrew, The attached patch seems to sort it for me, can you give it try on win32 and cygwin? cheers Mark --- pg_buffercache_pages.c.orig Sun Mar 13 04:36:24 2005 +++ pg_buffercache_pages.c Wed Mar 16 20:57:52 2005 @@ -17,6 +17,11 @@ #define NUM_BUFFERCACHE_PAGES_ELEM 6 +#ifdef WIN32 +extern DLLIMPORT BufferDesc *BufferDescriptors; +extern DLLIMPORT volatile uint32 InterruptHoldoffCount; +#endif + /* * Record structure holding the to be exposed cache data.
It fixes the build error on Windows - haven't tried because i don't have time, but I know it won't work on Cygwin, because WIN32 isn't (usually) defined on Cygwin - see previous almost endless discussions. cheers andrew Mark Kirkwood wrote: > Andrew Dunstan wrote: > >> ... is apparently broken for Windows and Cygwin. See for example >> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=loris&dt=2005-03-16%2001:55:33 >> >> > > Andrew, > > The attached patch seems to sort it for me, can you give it try on > win32 and cygwin? > > cheers > > Mark > >------------------------------------------------------------------------ > >--- pg_buffercache_pages.c.orig Sun Mar 13 04:36:24 2005 >+++ pg_buffercache_pages.c Wed Mar 16 20:57:52 2005 >@@ -17,6 +17,11 @@ > > #define NUM_BUFFERCACHE_PAGES_ELEM 6 > >+#ifdef WIN32 >+extern DLLIMPORT BufferDesc *BufferDescriptors; >+extern DLLIMPORT volatile uint32 InterruptHoldoffCount; >+#endif >+ > > /* > * Record structure holding the to be exposed cache data. > > >------------------------------------------------------------------------ > > >---------------------------(end of broadcast)--------------------------- >TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > >
Andrew Dunstan wrote: > It fixes the build error on Windows - haven't tried because i don't have > time, but I know it won't work on Cygwin, because WIN32 isn't (usually) > defined on Cygwin - see previous almost endless discussions. > Yes - I recall that discussion a while ago. This patch should sort the issue. One question, should I be using defined(__MINGW32__) as opposed to defined(WIN32)? I figured I didn't as in this case it is not necessary to distinguish between native and cygwin. regards Mark *** pg_buffercache_pages.h.orig Thu Mar 17 10:12:20 2005 --- pg_buffercache_pages.h Thu Mar 17 13:44:45 2005 *************** *** 15,18 **** --- 15,24 ---- extern Datum pg_buffercache_pages(PG_FUNCTION_ARGS); + /* A little hackery for Windows and Cygwin */ + #if defined (WIN32) || defined (__CYGWIN__) + extern DLLIMPORT BufferDesc *BufferDescriptors; + extern DLLIMPORT volatile uint32 InterruptHoldoffCount; + #endif + #endif /* PG_BUFFERCACHE_PAGES_H */
Mark Kirkwood wrote: > Andrew Dunstan wrote: > >> It fixes the build error on Windows - haven't tried because i don't have >> time, but I know it won't work on Cygwin, because WIN32 isn't (usually) >> defined on Cygwin - see previous almost endless discussions. >> > > Yes - I recall that discussion a while ago. > > This patch should sort the issue. > > One question, should I be using defined(__MINGW32__) as opposed to > defined(WIN32)? I figured I didn't as in this case it is not necessary > to distinguish between native and cygwin. > > You figured correctly. cheers andrew
Andrew Dunstan wrote: > > Mark Kirkwood wrote: > > >>Andrew Dunstan wrote: >> >> >>>It fixes the build error on Windows - haven't tried because i don't have >>>time, but I know it won't work on Cygwin, because WIN32 isn't (usually) >>>defined on Cygwin - see previous almost endless discussions. >>> >> >>Yes - I recall that discussion a while ago. >> >>This patch should sort the issue. >> >>One question, should I be using defined(__MINGW32__) as opposed to >>defined(WIN32)? I figured I didn't as in this case it is not necessary >>to distinguish between native and cygwin. >> >> > > > You figured correctly. > Oh, and thanks to your efforts with the automated build system this gets picked up now instead of lurking till after release - great work! cheers Mark
Hi, in case one use 'inherits' relationship to create a hierarchy of tables, table 'pg_inherits' stores for each table the information of which is its parent table. During the evaluation of a query like select * from Root; where Root is the 'root' table of our hierarchy, postgreSQL needs to find which tables are involved in the result (which tables belong to the hierarchy). My question is whether the way, in wich postgresql do this task, is a transitive closure on table 'pg_inherits' or there is a better approach implemented (like numbering scheme techniques etc.) ? If there is a related url, please send it to me.
Also i'd like to answer you if postgresQL has implemented rcursive queries proposed from SQL99 standard? If yes, are there any restrictions of the model on your implementation?
Ioannis Theoharis <theohari@ics.forth.gr> writes: > My question is whether the way, in wich postgresql do this task, is a > transitive closure on table 'pg_inherits' or there is a better approach > implemented (like numbering scheme techniques etc.) ? It's a transitive closure, and not a very bright one at that; see find_all_inheritors(), find_inheritance_children(), and particularly the comments to the latter. However, we've not heard reports indicating that this is a serious bottleneck in any real-world situation, so no one has spent time to improve it. (I'd expect the per-table planning costs to vastly outweigh the cost of finding those tables, anyway.) regards, tom lane