Re: [HACKERS] Fwd: pg_dump VS alter database ... set search_path ...
On 10/9/06, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote: Maybe my understanding is wrong - I'll be glad to hear why. Maybe at least to create special switcher for database settings? (It would remain backward compatibility...) -- Best regards, Nikolay ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Clarification needed
Hai, Can anyone of you help me in finding the datatype of a particular column in a table in Postgres? Thanks and Regards, M.Indira
Re: [HACKERS] Index Tuning Features
On 10/10/06, Mark Woodward <[EMAIL PROTECTED]> wrote: I think the idea of "virtual indexes" is pretty interesting, but ultimately a lesser solution to a more fundimental issue, and that would be "hands on" control over the planner. Estimating the effect of an index on a query "prior" to creating the index is a great idea, how that is done is something different than building concensus that it should be done. Another thing that this brings up is "hints" to a query. Over the years, I have run into situation where the planner wasn't great. It would be nice to try forcing different strategies on the planner and see if performance caan be improved. you can do this by setting enable_"access_method" type parameters. -- regards, Jaime Casanova "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning." Richard Cook ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Index Tuning Features
Mark, > Another thing that this brings up is "hints" to a query. Over the years, > I have run into situation where the planner wasn't great. It would be > nice to try forcing different strategies on the planner and see if > performance caan be improved. See discussion on -performance. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Change view ownership
On Tue, Oct 10, 2006 at 09:33:13PM -0400, Neil Conway wrote: > On Tue, 2006-10-10 at 20:27 -0500, Jim C. Nasby wrote: > > Wow, that's news to me. I'll prepare a docs patch to reflect that. > > It is already reflected in the docs, although it might need to be more > prominent. Yeah, it should be listed at the top of the page, IMO. > > Is there any other operations ALTER TABLE can perform on a view? > > IIRC, it can be used to rename an index, sequence, or view, and also to > add defaults to a view's columns. I don't see anything about indexes... I think it'd be best to move this functionality out of ALTER TABLE and put it in the appropriate ALTER commands (well, we can't move it out yet, but we should depricate it). -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Change view ownership
On Tue, 2006-10-10 at 20:27 -0500, Jim C. Nasby wrote: > Wow, that's news to me. I'll prepare a docs patch to reflect that. It is already reflected in the docs, although it might need to be more prominent. > Is there any other operations ALTER TABLE can perform on a view? IIRC, it can be used to rename an index, sequence, or view, and also to add defaults to a view's columns. -Neil ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Change view ownership
On Tue, Oct 10, 2006 at 09:23:34PM -0400, Neil Conway wrote: > On Tue, 2006-10-10 at 20:17 -0500, Jim C. Nasby wrote: > > IIRC there was an intention to allow ownership reassignment of all > > objects in the database. Somehow views got missed > > ALTER TABLE can change view ownership (as well as sequence ownership). > You could argue for the addition of an ALTER VIEW ... OWNER TO, but IMHO > it is not something that is urgent enough for inclusion in 8.2 Wow, that's news to me. I'll prepare a docs patch to reflect that. Is there any other operations ALTER TABLE can perform on a view? -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Change view ownership
On Tue, 2006-10-10 at 20:17 -0500, Jim C. Nasby wrote: > IIRC there was an intention to allow ownership reassignment of all > objects in the database. Somehow views got missed ALTER TABLE can change view ownership (as well as sequence ownership). You could argue for the addition of an ALTER VIEW ... OWNER TO, but IMHO it is not something that is urgent enough for inclusion in 8.2 -Neil ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Change view ownership
IIRC there was an intention to allow ownership reassignment of all objects in the database. Somehow views got missed (probably because they don't currently have an ALTER command). If there isn't a lot of code involved in making this happen, I'd argue it should go in as a bug fix. If not, can we add it to the TODO for 8.3? -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Index Tuning Features
> Simon Riggs <[EMAIL PROTECTED]> writes: >> - RECOMMEND command > >> Similar in usage to an EXPLAIN, the RECOMMEND command would return a >> list of indexes that need to be added to get the cheapest plan for a >> particular query (no explain plan result though). > > Both of these seem to assume that EXPLAIN results, without EXPLAIN > ANALYZE results to back them up, are sufficient for tuning. I find > this idea a bit dubious, particularly for cases of "marginal" indexes. I think the idea of "virtual indexes" is pretty interesting, but ultimately a lesser solution to a more fundimental issue, and that would be "hands on" control over the planner. Estimating the effect of an index on a query "prior" to creating the index is a great idea, how that is done is something different than building concensus that it should be done. Another thing that this brings up is "hints" to a query. Over the years, I have run into situation where the planner wasn't great. It would be nice to try forcing different strategies on the planner and see if performance caan be improved. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Index Tuning Features
Robert Treat <[EMAIL PROTECTED]> writes: > Anything that can be done to wheedle down your choices > before you have to run EXPLAIN ANALYZE is a bonus. Fair enough, but I prefer Peter's suggestion of attaching the hypothetical index definitions to EXPLAIN itself, rather than making bogus catalog entries. Something along the line of EXPLAIN ASSUMING INDEX fooi ON foo [ ASSUMING INDEX ... ] although this exact syntax probably doesn't work unless we're willing to make ASSUMING a fully reserved word :-( I have some vague recollection that this idea has been discussed before... regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] query optimization with UDFs
Neil Conway <[EMAIL PROTECTED]> writes: > BTW, I think it would make sense to implement a limited subset of the > xfunc ideas: add options to CREATE FUNCTION to allow cost information to > be specified, and then take advantage of this information instead of > using the existing constant kludges. This would be a tangible > improvement, and would have minimal impact on the planner. The trick is to figure out what a useful parameterized cost model would look like. IIRC, the main reason the xfunc code rotted on the vine was that its cost parameters didn't seem to be either easy to select or powerful in predicting actual cost. We'd have to do better this time. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2beta1 does not compile for me on Solaris 10
Tom Lane wrote: > This most likely means that libreadline depends on another shared > library (termcap maybe?) that isn't installed in your default search > path; so you'd need to set LD_LIBRARY_PATH or LD_RUN_PATH --- see > item 3 in our FAQ_Solaris for info. One would think that blastwave's > documentation for the package would warn about this though. The link editor looks in different places than the run-time linker, and that's why you need to give extra help to the run-time linker. It has nothing to do with readline, termcap, or blastwave. > I tend to agree with Andrew's solution of installing it in a more > standard place than /opt/csw ... That is the standard place. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pg_dump exclusion switches and functions/types
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes: >> Sure, but the question is whether that incremental gain in capability >> is worth the extra logical complexity. I'm inclined to think that many >> more users would get burned by the complexity than would have use for >> it. > I disagree - we lose a lot of flexibility by taking out the ordering, We lose some flexibility, but it's not clear to me that it's so essential as all that. Even the restricted patch is tremendously more flexible than pg_dump has ever been, and I just don't see the argument that there's a market demand for doing more at the cost of clarity. > I'm also not sure why the regex > should be changed to something even more non-standard than the current > POSIX ones. Finally, I'm surprised at the apparent willingness at this > point to shatter backwards-compatibility with previous -t scripts, as > this was an option I raised early on but met strong resistance, thus > the current compromise of allowing existing scripts to run unaltered, > while adding in the ability to do some regular expressions. That's a fair point, but the way that the patch was preserving exact backward compatibility was by making it a discontinuous corner case, which is a decision I think we'd regret in the long run. Andrew was already suggesting upthread that we drop the anchoring (and lose compatibility to a much greater extent than what this does) in order to make the behavior more self-consistent. Also, insisting on straight regexps amounts to failing to learn from experience: before 7.3 the psql \d commands used patterns that *were* straight regexps, and that just did not work all that conveniently. > The regex stuff was discussed in January, and the patch submitted in > July, so it seems a little rushed to be changing the underlying behavior > so quickly right now Well, the problem is that once we ship 8.2 we'll be stuck with whatever behavior we've defined --- it's unlikely that it'd be worth the pain of another round of incompatibility in order to make small adjustments. So we'd better get it right the first time. I do apologize for not having reviewed this patch more closely earlier, but I've been a tad busy... regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Index Tuning Features
On Tuesday 10 October 2006 12:06, Tom Lane wrote:
> > Similar in usage to an EXPLAIN, the RECOMMEND command would return a
> > list of indexes that need to be added to get the cheapest plan for a
> > particular query (no explain plan result though).
>
> Both of these seem to assume that EXPLAIN results, without EXPLAIN
> ANALYZE results to back them up, are sufficient for tuning. I find
> this idea a bit dubious, particularly for cases of "marginal" indexes.
>
While I agree with Tom that generally EXPLAIN is not enough for tuning, I also
know that when your dealing with queries that have run times in multiples of
hours (and the corresponding hour long index builds) EXPLAIN ANALYZE just
isn't an option. Anything that can be done to wheedle down your choices
before you have to run EXPLAIN ANALYZE is a bonus.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2beta1 does not compile for me on Solaris 10
Joseph S writes: > I'm attaching the whole log. It appears that blastwave's version of readline passes the link test: > configure:6320: checking for -lreadline > configure:6347: gcc -o conftest -O2 -Wall -Wmissing-prototypes > -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels > -fno-strict-aliasing -g -I/opt/csw/include -L/opt/csw/lib conftest.c > -lreadline -lrt -lsocket -lm >&5 > configure:6353: $? = 0 but fails at execution: > configure:17432: checking test program > configure:17447: gcc -o conftest -O2 -Wall -Wmissing-prototypes > -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels > -fno-strict-aliasing -g -I/opt/csw/include -L/opt/csw/lib conftest.c -lz > -lreadline -lrt -lsocket -lm >&5 > configure:17450: $? = 0 > configure:17452: ./conftest > ld.so.1: ./conftest: fatal: libreadline.so.5: open failed: No such file or > directory > ./configure: line 17453: 9775 Killed ./conftest$ac_exeext > configure:17455: $? = 137 > configure: program exited with status 137 This most likely means that libreadline depends on another shared library (termcap maybe?) that isn't installed in your default search path; so you'd need to set LD_LIBRARY_PATH or LD_RUN_PATH --- see item 3 in our FAQ_Solaris for info. One would think that blastwave's documentation for the package would warn about this though. I tend to agree with Andrew's solution of installing it in a more standard place than /opt/csw ... regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] TupleDesc for a Nested Record
Hi, While returning from a function call, PL can easily interfere will be returned HeapTuple's TupleDesc from fcinfo. But what if function returns a record type? Then we must create our own TupleDesc (or AttInMetadata) for the related attribute (and then create HeapTuple). So far everything is ok, but how can I interfere the data types in the nested record? This isn't supplied by fcinfo. What would you suggest in such a situation? Regards. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2beta1 does not compile for me on Solaris 10
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Joseph S wrote: >> checking test program... failed >> configure: error: >> *** Could not execute a simple test program. This may be a problem >> *** related to locating shared libraries. Check the file 'config.log' >> *** for the exact reason. > I had similar issues, which is why I installed a private copy of readline. This suggests that blastwave's version of readline needs some help, but if you want to find out what went wrong you need to do more work than "tail config.log". The last several hundred lines of output in that file will usually just be configure dumping all its internal variables --- everything after the comment ## ## ## Cache variables. ## ## ## is usually unhelpful in my experience. You have to look at the output from the failed test itself, just above that. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2beta1 does not compile for me on Solaris 10
Joseph, How about just compiling --without-readline? Also, if you have Sun Studio 11 available, you'll get better performance out of your PostgreSQL. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2beta1 does not compile for me on Solaris 10
Joseph S wrote: Tom Lane wrote: Joseph S writes: Anyway I installed the readline package from blastwave but the configure script still didn't find it. Where does blastwave put it? You likely need --with-includes and/or --with=libraries switches to tell configure where to look. regards, tom lane If I run: ./configure --enable-debug --with-cassert --with-includes=/opt/csw/include --with-libraries=/opt/csw/lib it gets past the readline problem, but fails later with: checking for _LARGEFILE_SOURCE value needed for large files... no checking for fseeko... (cached) yes checking test program... failed configure: error: *** Could not execute a simple test program. This may be a problem *** related to locating shared libraries. Check the file 'config.log' *** for the exact reason. $ tail config.log #define PACKAGE_NAME "PostgreSQL" #define PACKAGE_STRING "PostgreSQL 8.2beta1" #define PACKAGE_TARNAME "postgresql" #define PACKAGE_VERSION "8.2beta1" #define PG_KRB_SRVNAM "postgres" #define PG_VERSION "8.2beta1" #define PG_VERSION_NUM 80200 #define PG_VERSION_STR "PostgreSQL 8.2beta1 on i386-pc-solaris2.10, compiled by GCC gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)" configure: exit 1 I had similar issues, which is why I installed a private copy of readline. See working config at http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=hyena&dt=2006-10-10%20012001&stg=config cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Updated version of FAQ_Solaris
Zdenek Kotala wrote: > + The PostgreSQL 8.2 has implemented dtrace support. You can enable it by > + the --enable-dtrace configure switch. If you want to compile a 64-bit code > + with dtrace you must specify DTRACEFLAGS='-64', e.g. This is contrary to the documentation of the dtrace command which says that dtrace will automatically compile for the host environment. Please explain. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2beta1 does not compile for me on Solaris 10
Joseph S wrote: Josh Berkus wrote: Use --without-readline to disable readline support. [EMAIL PROTECTED] ~/postgresql-8.2beta1]$ uname -a SunOS xx 5.10 Generic i86pc i386 i86pc Do you have readline installed? It's not standard on Solaris. I don't know if it's even available from Blastwave. Apparently it is. http://www.blastwave.org/packages.php/readline postgresql is listed as one of the packages that depends on readline. Anyway I installed the readline package from blastwave but the configure script still didn't find it. blastwave installs packages in /opt/csw -- so you have to point configure to the directory if you are going to use that package -- I usually use the packages from sunfreeware.com which installs in /usr/local. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2beta1 does not compile for me on Solaris 10
Tom Lane wrote: Joseph S writes: Anyway I installed the readline package from blastwave but the configure script still didn't find it. Where does blastwave put it? You likely need --with-includes and/or --with=libraries switches to tell configure where to look. regards, tom lane If I run: ./configure --enable-debug --with-cassert --with-includes=/opt/csw/include --with-libraries=/opt/csw/lib it gets past the readline problem, but fails later with: checking for _LARGEFILE_SOURCE value needed for large files... no checking for fseeko... (cached) yes checking test program... failed configure: error: *** Could not execute a simple test program. This may be a problem *** related to locating shared libraries. Check the file 'config.log' *** for the exact reason. $ tail config.log #define PACKAGE_NAME "PostgreSQL" #define PACKAGE_STRING "PostgreSQL 8.2beta1" #define PACKAGE_TARNAME "postgresql" #define PACKAGE_VERSION "8.2beta1" #define PG_KRB_SRVNAM "postgres" #define PG_VERSION "8.2beta1" #define PG_VERSION_NUM 80200 #define PG_VERSION_STR "PostgreSQL 8.2beta1 on i386-pc-solaris2.10, compiled by GCC gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)" configure: exit 1 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2beta1 does not compile for me on Solaris 10
Joseph S writes: > Anyway I installed the readline package from blastwave but the configure > script still didn't find it. Where does blastwave put it? You likely need --with-includes and/or --with=libraries switches to tell configure where to look. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2beta1 does not compile for me on Solaris 10
Joseph S wrote: Joshua D. Drake wrote: Joseph Shraibman wrote: [EMAIL PROTECTED] ~/postgresql-8.2beta1]$ ./configure --enable-debug --with-cassert configure: error: readline library not found If you have readline already installed, see config.log for details on the failure. It is possible the compiler isn't looking in the proper directory. Use --without-readline to disable readline support. [EMAIL PROTECTED] ~/postgresql-8.2beta1]$ uname -a SunOS xx 5.10 Generic i86pc i386 i86pc Do you have readline installed? Apparently not. Of course it could be in some strange place where neither I nor the configure script can find it. Solaris is like that. I don't run postgresql on Solaris, I just happened to have a Solaris box on which I could test compile the beta, and I'm reporting the results. I had to install a private copy of readline on buildfarm hyena to get it working there. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2beta1 does not compile for me on Solaris 10
Josh Berkus wrote: Use --without-readline to disable readline support. [EMAIL PROTECTED] ~/postgresql-8.2beta1]$ uname -a SunOS xx 5.10 Generic i86pc i386 i86pc Do you have readline installed? It's not standard on Solaris. I don't know if it's even available from Blastwave. Apparently it is. http://www.blastwave.org/packages.php/readline postgresql is listed as one of the packages that depends on readline. Anyway I installed the readline package from blastwave but the configure script still didn't find it. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2beta1 does not compile for me on Solaris 10
Joshua D. Drake wrote: Joseph Shraibman wrote: [EMAIL PROTECTED] ~/postgresql-8.2beta1]$ ./configure --enable-debug --with-cassert configure: error: readline library not found If you have readline already installed, see config.log for details on the failure. It is possible the compiler isn't looking in the proper directory. Use --without-readline to disable readline support. [EMAIL PROTECTED] ~/postgresql-8.2beta1]$ uname -a SunOS xx 5.10 Generic i86pc i386 i86pc Do you have readline installed? Apparently not. Of course it could be in some strange place where neither I nor the configure script can find it. Solaris is like that. I don't run postgresql on Solaris, I just happened to have a Solaris box on which I could test compile the beta, and I'm reporting the results. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.2beta1 does not compile for me on Solaris 10
> > Use --without-readline to disable readline support. > > [EMAIL PROTECTED] ~/postgresql-8.2beta1]$ uname -a > > SunOS xx 5.10 Generic i86pc i386 i86pc > > Do you have readline installed? It's not standard on Solaris. I don't know if it's even available from Blastwave. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Blindly back-patching FAQs is not such a hot
Tom Lane wrote: > ... as an example, I see you removed material from 8.1's FAQ_HPUX that > is still relevant to that branch. Are we trimming platform-specific FAQs as we move forward? I figured an FAQ just got more accurate. And I only backpatch to the most recent branch. Are you talking about this? - The parallel regression test script (gmake check) is known to lock up - on PA-RISC when run under HP's Bourne shells: /usr/bin/sh and - /sbin/sh. To fix this problem, you will need PHCO_30269 with its - dependent patch or successor patches: - - PHCO_30269 s700_800 cumulative sh-posix(1) patch - PHCO_29816 s700_800 rc(1M) scripts cumulative patch - - To work around this problem, use ksh to run the regression script: - - gmake SHELL=/bin/ksh check - - If you see that the tests have stopped making progress and only a shell - process is consuming CPU, kill the shell process and start over with the - above command. This was removed in CVS HEAD, but it imagine it applies to 8.1.X because the regression test is still a shell script in 8.1.X. I will re-add it, but in general it seems like we win more than lose by copying the FAQ's backward, partly because I don't usually apply them to the back branches. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2beta1 does not compile for me on Solaris 10
Joseph Shraibman wrote: > [EMAIL PROTECTED] ~/postgresql-8.2beta1]$ ./configure --enable-debug > --with-cassert > configure: error: readline library not found > If you have readline already installed, see config.log for details on the > failure. It is possible the compiler isn't looking in the proper > directory. > Use --without-readline to disable readline support. > [EMAIL PROTECTED] ~/postgresql-8.2beta1]$ uname -a > SunOS xx 5.10 Generic i86pc i386 i86pc Do you have readline installed? Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] 8.2beta1 does not compile for me on Solaris 10
[EMAIL PROTECTED] ~/postgresql-8.2beta1]$ ./configure --enable-debug --with-cassert checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking which template to use... solaris checking whether to build with 64-bit integer date/time support... no checking whether NLS is wanted... no checking for default port number... 5432 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking if gcc supports -Wdeclaration-after-statement... yes checking if gcc supports -Wendif-labels... yes checking if gcc supports -fno-strict-aliasing... yes configure: using CFLAGS=-O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g checking whether the C compiler still works... yes checking how to run the C preprocessor... gcc -E checking allow thread-safe client libraries... no checking whether to build with Tcl... no checking whether to build Perl modules... no checking whether to build Python modules... no checking whether to build with Kerberos 5 support... no checking whether to build with PAM support... no checking whether to build with LDAP support... no checking whether to build with Bonjour support... no checking whether to build with OpenSSL support... no checking for egrep... egrep configure: using CPPFLAGS= configure: using LDFLAGS= checking for gawk... no checking for mawk... no checking for nawk... nawk checking for flex... /usr/sfw/bin/flex checking whether ln -s works... yes checking for ld used by GCC... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for ranlib... ranlib checking for tar... /usr/bin/tar checking for strip... strip checking whether it is possible to strip libraries... no checking for bison... bison -y checking for perl... /usr/bin/perl checking for library containing setproctitle... no checking for library containing pow... -lm checking for library containing dlopen... none required checking for library containing socket... -lsocket checking for library containing shl_load... no checking for library containing getopt_long... none required checking for library containing crypt... none required checking for library containing fdatasync... -lrt checking for library containing shmget... none required checking for -lreadline... no checking for -ledit... no configure: error: readline library not found If you have readline already installed, see config.log for details on the failure. It is possible the compiler isn't looking in the proper directory. Use --without-readline to disable readline support. [EMAIL PROTECTED] ~/postgresql-8.2beta1]$ uname -a SunOS xx 5.10 Generic i86pc i386 i86pc config.log ends with: ## --- ## ## confdefs.h. ## ## --- ## #define DEF_PGPORT 5432 #define DEF_PGPORT_STR "5432" #define PACKAGE_BUGREPORT "pgsql-bugs@postgresql.org" #define PACKAGE_NAME "PostgreSQL" #define PACKAGE_STRING "PostgreSQL 8.2beta1" #define PACKAGE_TARNAME "postgresql" #define PACKAGE_VERSION "8.2beta1" #define PG_KRB_SRVNAM "postgres" #define PG_VERSION "8.2beta1" #define PG_VERSION_NUM 80200 #define PG_VERSION_STR "PostgreSQL 8.2beta1 on i386-pc-solaris2.10, compiled by GCC gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)" configure: exit 1 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Blindly back-patching FAQs is not such a hot idea
... as an example, I see you removed material from 8.1's FAQ_HPUX that is still relevant to that branch. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Index Tuning Features
On Tue, Oct 10, 2006 at 06:06:09PM +0200, Peter Eisentraut wrote: > Simon Riggs wrote: > > For 8.3, I'd like to add the following two related features to assist > > with Index Tuning and usability: > > > > - Virtual Indexes > > This seems useful, but I'm not sure we need a catalog object for that. > It might be sufficient to declare these hypothetical indexes within the > EXPLAIN command. That is after all the only place where they are > applied. If you wanted to try multiple scenarios, that might become a pain. I guess it depends on how verbose the syntax was... > > - RECOMMEND command > > > > Similar in usage to an EXPLAIN, the RECOMMEND command would return a > > list of indexes that need to be added to get the cheapest plan for a > > particular query (no explain plan result though). > > This functionality also seems useful, but maybe it should be the job of > a user-space tool? I think it makes the most sense to have this in core, though I guess an argument could be made for having it be seperate from the backend. But it'd have to be easy to call from an external tool, such as pgAdmin, which means in probably needs to speak libpq. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] archive_timeout?
Jeff Davis <[EMAIL PROTECTED]> writes: > Maybe I just don't understand checkpoint timeout? Could it reasonably be > set to something like 12 hours? I can't think why not, but the config > default is 5 minutes, so I would be hesitant to change it by that much. The only constraining factor on it is how much WAL data are you willing to replay in order to recover from a crash. If you've got a low-volume database then replaying up to 12 hours' worth of activity might not be unacceptable. Also, if you have spikes of activity, then checkpoint_segments would kick in after a spike had generated X amount of data. So I don't see any strong reason why it couldn't be set much higher than archive_timeout. Now the other side of the coin is that if you do have a steady low level of activity then a small archive_timeout is still going to result in shipping lots of partially-filled WAL files. Compression might help some, but the bottom line is simply that archive_timeout isn't an efficient mechanism for dealing with low-volume databases. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] archive_timeout?
On Tue, 2006-10-10 at 13:12 -0400, Tom Lane wrote: > Jeff Davis <[EMAIL PROTECTED]> writes: > > There should be a documentation note to let people know that the archive > > will grow even when idle. Perhaps we should suggest compression in the > > docs so that people don't get worried about many gigabytes of mostly- > > empty files filling up their backup storage. > > Actually, per the previous discussion: if you want to reduce WAL traffic > then one of the most important things to do is stretch out > checkpoint_timeout. > I assume you refer to this message: http://archives.postgresql.org/pgsql-hackers/2006-08/msg01190.php I understand that stretching the checkpoint timeout is useful if you have steady traffic and want to reduce the WAL volume. Higher checkpoint intervals mean fewer copies of data pages (at least before 8.2), and probably other data necessary at checkpoint. However, if you have a database with long idle times, higher checkpoint intervals combined with archive_timeout can still waste a lot of data (unless you stretch out the checkpoint timeout by orders of magnitude). This situation is also most the most useful situation for archive_timeout. If someone is concerned about idle time eating up gigabytes of backup storage, compression seems like a logical choice. Maybe I just don't understand checkpoint timeout? Could it reasonably be set to something like 12 hours? I can't think why not, but the config default is 5 minutes, so I would be hesitant to change it by that much. Regards, Jeff Davis ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] continuing daily testing of dbt2 against postgresql
Yeah, I'm sure binding each process to a CPU would be a significant help. Something I've always wanted to quantify but haven't made time for... Mark Luke Lonergan wrote: One of our customers noticed that there were a high number of NUMA cache misses on a quad core opteron system running Bizgres MPP resulting in about a 15% performance hit. We use a process-based parallelization approach and we can guess that there's context switching due to the high degree of pipeline parallelism in our executions plans. Each context switch likely switches a process away from the CPU with local memory, resulting in the NUMA cache misses. The answer for us is to bind each process to a CPU. Might that help in running DBT-2? - Luke On 10/10/06 9:40 AM, "Mark Wong" <[EMAIL PROTECTED]> wrote: Luke Lonergan wrote: +1 Mark, can you quantify the impact of not running with IRQ balancing enabled? Whoops, look like performance was due more to enabling the --enable-thread-safe flag. IRQ balancing on : 7086.75 http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/158/ IRQ balancing off: 7057.90 http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/163/ The interrupt charts look completely different. There's too much stuff on the chart to determine what interrupts are from what though. :( It needs to be redone per processor (as opposed to per interrupt per processor) to be more useful in determining if one processor is overloaded due to interrupts. http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/158/report/sar/sar-intr.png http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/163/report/sar/sar-intr.png But the sum of all the interrupts handled are close between tests so it seems clear no single processor was overloaded: http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/158/report/sar/sar-intr_s.png http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/163/report/sar/sar-intr_s.png Mark ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] archive_timeout?
Jeff Davis <[EMAIL PROTECTED]> writes: > There should be a documentation note to let people know that the archive > will grow even when idle. Perhaps we should suggest compression in the > docs so that people don't get worried about many gigabytes of mostly- > empty files filling up their backup storage. Actually, per the previous discussion: if you want to reduce WAL traffic then one of the most important things to do is stretch out checkpoint_timeout. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] archive_timeout?
On Tue, 2006-10-10 at 22:26 +0900, Tatsuo Ishii wrote: > If archive_timeout is set to non 0, it seems an archive log segment is > created every time checkpoint occurs even there's no database > updation. This leads to creating 16MB log segment files every 5 > minutes (default checkpoint period), which will in turn produce 4.6GB > log segments with bogus data. Is this normal? > > This is PostgreSQL 8.2 beta1. If the WAL is pretty much empty, gzip brings it from 16MB down to about 16KB, which is much more reasonable. I've noticed that even when idle there are a few files that seem to compress only to about 32KB, and some only to 880KB. I don't know exactly why those files are different, perhaps something with the stats collector? Autovacuum was off for this test. There should be a documentation note to let people know that the archive will grow even when idle. Perhaps we should suggest compression in the docs so that people don't get worried about many gigabytes of mostly- empty files filling up their backup storage. Regards, Jeff Davis ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] continuing daily testing of dbt2 against
One of our customers noticed that there were a high number of NUMA cache misses on a quad core opteron system running Bizgres MPP resulting in about a 15% performance hit. We use a process-based parallelization approach and we can guess that there's context switching due to the high degree of pipeline parallelism in our executions plans. Each context switch likely switches a process away from the CPU with local memory, resulting in the NUMA cache misses. The answer for us is to bind each process to a CPU. Might that help in running DBT-2? - Luke On 10/10/06 9:40 AM, "Mark Wong" <[EMAIL PROTECTED]> wrote: > Luke Lonergan wrote: >> +1 >> >> Mark, can you quantify the impact of not running with IRQ balancing enabled? > > Whoops, look like performance was due more to enabling the > --enable-thread-safe flag. > > IRQ balancing on : 7086.75 > http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/158/ > IRQ balancing off: 7057.90 > http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/163/ > > The interrupt charts look completely different. There's too much stuff > on the chart to determine what interrupts are from what though. :( It > needs to be redone per processor (as opposed to per interrupt per > processor) to be more useful in determining if one processor is > overloaded due to interrupts. > > http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/158/report/sar/sar-intr.png > http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/163/report/sar/sar-intr.png > > But the sum of all the interrupts handled are close between tests so it > seems clear no single processor was overloaded: > > http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/158/report/sar/sar-intr_s.png > http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/163/report/sar/sar-intr_s.png > > Mark > ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] continuing daily testing of dbt2 against postgresql
Luke Lonergan wrote: +1 Mark, can you quantify the impact of not running with IRQ balancing enabled? Whoops, look like performance was due more to enabling the --enable-thread-safe flag. IRQ balancing on : 7086.75 http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/158/ IRQ balancing off: 7057.90 http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/163/ The interrupt charts look completely different. There's too much stuff on the chart to determine what interrupts are from what though. :( It needs to be redone per processor (as opposed to per interrupt per processor) to be more useful in determining if one processor is overloaded due to interrupts. http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/158/report/sar/sar-intr.png http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/163/report/sar/sar-intr.png But the sum of all the interrupts handled are close between tests so it seems clear no single processor was overloaded: http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/158/report/sar/sar-intr_s.png http://dbt.osdl.org/dbt/dbt2dev/results/dev4-015/163/report/sar/sar-intr_s.png Mark ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Index Tuning Features
Peter Eisentraut wrote: > Simon Riggs wrote: >> For 8.3, I'd like to add the following two related features to assist >> with Index Tuning and usability: >> >> - Virtual Indexes > > This seems useful, but I'm not sure we need a catalog object for that. > It might be sufficient to declare these hypothetical indexes within the > EXPLAIN command. That is after all the only place where they are > applied. > >> - RECOMMEND command >> >> Similar in usage to an EXPLAIN, the RECOMMEND command would return a >> list of indexes that need to be added to get the cheapest plan for a >> particular query (no explain plan result though). > > This functionality also seems useful, but maybe it should be the job of > a user-space tool? On this same vein I thought it would be interesting if we added a suggestion to explain analyze... Something like: Your estimated number of rows appears to be off. Have you ran analyze lately? Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Index Tuning Features
Simon Riggs <[EMAIL PROTECTED]> writes: > - Virtual Indexes > An index which only exists in the catalog, so is visible to the planner > but not the executor. Say what? What would that possibly be useful for, other than crashing any bit of code that failed to know about it? > - RECOMMEND command > Similar in usage to an EXPLAIN, the RECOMMEND command would return a > list of indexes that need to be added to get the cheapest plan for a > particular query (no explain plan result though). Both of these seem to assume that EXPLAIN results, without EXPLAIN ANALYZE results to back them up, are sufficient for tuning. I find this idea a bit dubious, particularly for cases of "marginal" indexes. > Specifically, multi-column indexes are not considered very heavily in > RECOMMEND. That seems like a bad idea as well --- multicol indexes are exactly the sort of thing a novice DBA might fail to consider. If you're going to do this then you should consider all cases. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Index Tuning Features
Simon Riggs wrote: > For 8.3, I'd like to add the following two related features to assist > with Index Tuning and usability: > > - Virtual Indexes This seems useful, but I'm not sure we need a catalog object for that. It might be sufficient to declare these hypothetical indexes within the EXPLAIN command. That is after all the only place where they are applied. > - RECOMMEND command > > Similar in usage to an EXPLAIN, the RECOMMEND command would return a > list of indexes that need to be added to get the cheapest plan for a > particular query (no explain plan result though). This functionality also seems useful, but maybe it should be the job of a user-space tool? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Index Tuning Features
For 8.3, I'd like to add the following two related features to assist with Index Tuning and usability: - Virtual Indexes An index which only exists in the catalog, so is visible to the planner but not the executor. This is useful where a specific SQL query is being hand-tuned, allowing very specific options to be selected. Virtual indexes would only be seen by the planner when performing an EXPLAIN and when enable_virtual_index = on (default: off, Userset). Normal SQL statements would ignore them completely, whatever enable_virtual_index is set to. It would not be possible to have both a virtual and a real index defined identically at the same time. (If facilities existed to make temporary tables exist only for a single backend, rather than requiring catalog access then that implementation route would also work here, but until that does, simple updates seem fine). SQL: CREATE [VIRTUAL] [UNIQUE] INDEX ... - RECOMMEND command Similar in usage to an EXPLAIN, the RECOMMEND command would return a list of indexes that need to be added to get the cheapest plan for a particular query (no explain plan result though). At planning time, all possible single column indexes would be assumed to exist, plus all groups of cols that make up a multi-col Foreign Key would be assumed to make a multi-col index. (PKs always exist, remember). We track whether hypothetical indexes exist on the plan, so once the cheapest plan has been decided we can report what they are (if any). Hypothetical indexes last only for the duration of planning - no catalog changes are made. Command will return 1 row per selected index (can be more than one for a complex query), first col gives list of indexed cols, second col shows the SQL required to create that index. Virtual indexes will be noted, though treated identically to hypothetical indexes. The changes to do this would not be very invasive to the planner and mainly involve adding additional fields to the planner data structures, some additional branching code and command changes/additions. Overall we need both of these new features: RECOMMEND covers many cases in an easy to use form, with VIRTUAL indexes covers the rest of the search space for possible new indexes for specific cases. There's a host of other little tweaky bits we might imagine to enhance this capability further, but this seems to cover the basic requirements. Specifically, multi-column indexes are not considered very heavily in RECOMMEND. This is deliberate because a) we don't have good multi-col interaction stats (though we might have for 8.3?) b) it greatly increases the run-time of exhaustive searching and c) because we have bitmap index interaction the usefulness of multi-column indexes is much reduced anyhow, so cost/benefit not good. Comments? (I'll do a summary of feedback tomorrow.) -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] test: please ignore
> >> I've posted a 6.5kB patch (as an attachment) three times over > the > >> past few days but haven't seen it hit the lists. Checking to see > if > >> this goes through. > > > Did you by any chance gzip it? IIRC, mails with gzipped > attachments > > are silently dropped on- patches for some reason. > > Hm? They've always worked fine for me, and for a lot of other > people. > You should ask Marc to look into this. I did. You even confirmed that you had the same problem. See: http://archives.postgresql.org/pgsql-patches/2006-08/msg00256.php http://archives.postgresql.org/pgsql-patches/2006-08/msg00273.php //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] test: please ignore
Tom Lane wrote: > "Magnus Hagander" <[EMAIL PROTECTED]> writes: > >> I've posted a 6.5kB patch (as an attachment) three times over the > >> past few days but haven't seen it hit the lists. Checking to see if > >> this goes through. > > > Did you by any chance gzip it? IIRC, mails with gzipped attachments are > > silently dropped on- patches for some reason. > > Hm? They've always worked fine for me, and for a lot of other people. > You should ask Marc to look into this. It depends on the MIME type IIRC. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] test: please ignore
"Magnus Hagander" <[EMAIL PROTECTED]> writes: >> I've posted a 6.5kB patch (as an attachment) three times over the >> past few days but haven't seen it hit the lists. Checking to see if >> this goes through. > Did you by any chance gzip it? IIRC, mails with gzipped attachments are > silently dropped on- patches for some reason. Hm? They've always worked fine for me, and for a lot of other people. You should ask Marc to look into this. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Upgrading a database dump/restore
Benny Amorsen wrote: "TL" == Tom Lane <[EMAIL PROTECTED]> writes: TL> (I suppose it wouldn't work in Windows for lack of hard links, but TL> anyone trying to run a terabyte database on Windows deserves to TL> lose anyway.) Windows has hard links on NTFS, they are just rarely used. And MS provides a command line utility to create them. See http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil_hardlink.mspx?mfr=true I imagine there is also a library call that can be made to achieve the same effect. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] archive_timeout?
Tatsuo Ishii <[EMAIL PROTECTED]> writes: > If archive_timeout is set to non 0, it seems an archive log segment is > created every time checkpoint occurs even there's no database > updation. This leads to creating 16MB log segment files every 5 > minutes (default checkpoint period), which will in turn produce 4.6GB > log segments with bogus data. Is this normal? Yeah, that was intentional, see discussion a few weeks ago. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] archive_timeout?
If archive_timeout is set to non 0, it seems an archive log segment is created every time checkpoint occurs even there's no database updation. This leads to creating 16MB log segment files every 5 minutes (default checkpoint period), which will in turn produce 4.6GB log segments with bogus data. Is this normal? This is PostgreSQL 8.2 beta1. -- Tatsuo Ishii SRA OSS, Inc. Japan ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] archive_timeout?
> If archive_timeout is set to non 0, it seems an archive log segment is > created every time checkpoint occurs even there's no database > updation. This leads to creating 16MB log segment files every 5 > minutes (default checkpoint period), which will in turn produce 4.6GB > log segments with bogus data. Is this normal? I mean 4.6GB per day. > This is PostgreSQL 8.2 beta1. > -- > Tatsuo Ishii > SRA OSS, Inc. Japan > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend > ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Upgrading a database dump/restore
> -Original Message- > From: Magnus Hagander [mailto:[EMAIL PROTECTED] > Sent: 10 October 2006 13:23 > To: Dave Page; Benny Amorsen; pgsql-hackers@postgresql.org > Subject: RE: [HACKERS] Upgrading a database dump/restore > > > > TL> (I suppose it wouldn't work in Windows for lack of hard > > links, but > > > TL> anyone trying to run a terabyte database on Windows deserves > > to > > > TL> lose anyway.) > > > > > > Windows has hard links on NTFS, they are just rarely used. > > > > We use them in PostgreSQL to support tablespaces. > > No, we don't. We use NTFS Junctions which are the equivalent of > directory *symlinks*. Not hardlinks. Different thing. They are? Oh well, you live and learn :-) /D ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Upgrading a database dump/restore
> > TL> (I suppose it wouldn't work in Windows for lack of hard > links, but > > TL> anyone trying to run a terabyte database on Windows deserves > to > > TL> lose anyway.) > > > > Windows has hard links on NTFS, they are just rarely used. > > We use them in PostgreSQL to support tablespaces. No, we don't. We use NTFS Junctions which are the equivalent of directory *symlinks*. Not hardlinks. Different thing. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Upgrading a database dump/restore
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Benny Amorsen > Sent: 10 October 2006 13:02 > To: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Upgrading a database dump/restore > > > "TL" == Tom Lane <[EMAIL PROTECTED]> writes: > > TL> (I suppose it wouldn't work in Windows for lack of hard links, but > TL> anyone trying to run a terabyte database on Windows deserves to > TL> lose anyway.) > > Windows has hard links on NTFS, they are just rarely used. We use them in PostgreSQL to support tablespaces. Regards, Dave. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Upgrading a database dump/restore
> "TL" == Tom Lane <[EMAIL PROTECTED]> writes: TL> (I suppose it wouldn't work in Windows for lack of hard links, but TL> anyone trying to run a terabyte database on Windows deserves to TL> lose anyway.) Windows has hard links on NTFS, they are just rarely used. /Benny ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] Generic Monitoring Framework with DTrace patch
Peter Eisentraut wrote: Robert Treat wrote: Also should installation.sgml mention the issueswith building 32 vs 64 bit binaries I'm not convinced there is an issue. dtrace will build the right binaries by default. If you're messing with mixed environments *and* delve into dtrace, you should probably be able to figure this out yourself. None that I'm aware of. and/or the issue with static functions? The issue with that is simply that there is no released operating system version for which the dtrace support works. I'm not sure what to do about that. This is a very temporary issue, and it will just require PostgreSQL to be built on the lastest version of Solaris (e.g Solaris Express), but the binary can will run just fine on the FCS version (e.g. Solaris 10). This will be clarified in the doc patch. -Robert ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Generic Monitoring Framework with DTrace patch
Sorry for the delayed response. Robert Treat wrote: Looking through -patches I don't see the doc patch, and outside of installation.sgml there doesn't seem to be anything either. Robert, are you still on the hook for these? Josh will help submit the doc patch. I have documented the usage instructions in a couple of places but just have been too busy to get the patch submitted. My bad. http://pgfoundry.org/docman/?group_id=1000163 http://blogs.sun.com/robertlor Also should installation.sgml mention the issues with building 32 vs 64 bit binaries and/or the issue with static functions? There are no issues with building 32 and 64 bit binaries. The above doc explains the issue with static function. Regards, -Robert ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] test: please ignore
> I've posted a 6.5kB patch (as an attachment) three times over the > past few days but haven't seen it hit the lists. Checking to see if > this goes through. Did you by any chance gzip it? IIRC, mails with gzipped attachments are silently dropped on- patches for some reason. (Can't remember if it was all gzip or just tar.gz, but it was dropped. You can find a discussion about it in the archives around when i posted the msvc build patch stuff, sometime this summer a couple of days after the conference) //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [JDBC] Test of 8.2beta1 fails
Per Jensen wrote: List, First of all, I am not sure this list is the right one to write to. I am trying out the postgresql 8.2.beta1 with the jdbc driver contained in ' postgresql-8.2dev-503.jdbc3.jar' downloaded from 'jdbc.postgresql.org'. The database is accessed through iBatis version 1.3.1 --> jakarta DBCP 1.2.1 I have dumped a production database from a debian sarge-PG7.4 instance and restored onto a test PG-8.1.3. This works nicely. The same dump restored to a test PG-8.2.beta1 works not quite as well, some queries succeed and some fail. This looks like a backend crash. I've CC'd the pgsql-hackers list. Could you capture the failing SQL query, please? If you could send it to the list, it would help us to diagnose the problem. Also, could you try to run it in psql and see if it crashes then as well? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
