Re: [Slony1-general] Re: [HACKERS] dangling lock information?
The slony log trigger saves execution plans, so any given connection that has been used with a slony schema installed will have cached OIDs referring to the sl_log_1 table. When you drop the schema, those OIDs obviously go away. When you re-create the schema, and try to use the old connection, it still has the old plan cached in it, so the OIDs in the plan are out of sync with what actually exists in the database. This is the behavior I've observed in our environment, anyway. The problem always shows up when slony is RE-installed under an outstanding connection. - DAP -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hannu Krosing Sent: Tuesday, August 30, 2005 7:28 AM To: Andreas Pflug Cc: slony1-general@gborg.postgresql.org; PostgreSQL-development Subject: [Slony1-general] Re: [HACKERS] dangling lock information? On E, 2005-08-29 at 13:09 +0200, Andreas Pflug wrote: > Hannu Krosing wrote: > > >On P, 2005-08-28 at 22:23 +0200, Andreas Pflug wrote: > > > > > >>I'm currently testing pgAdmin support for slony, on pgsql CVS HEAD, > >>and encounter strange problems from time to time. > >>After dropping and recreating the slony schema, all changes > >>committed and all backends in state, I'm getting "relation > >>with OID xxx does not exist" when I'm trying to add a path. > >>This seems to be triggered inside slony functions when a > >>LOCK _test.pg_config IN EXCLUSIVE MODE is performed. > >>The problem is gone as soon as I close the connection I've been > >>using for prior schema changes, and use a fresh connection. > >> > >>Does this description ring a bell for somebody? > >> > >> > > > >seems like the usual "pl/pgsql caches query plans and relation > >referenced inside the cached plan is gone" thing > > > > > Kind of, but the complete schema including procedures was dropped, so > apparently after recreation the old plans were reused?!? In that case this should probably be asked at slony list. Added to CC. -- Hannu Krosing <[EMAIL PROTECTED]> ___ Slony1-general mailing list Slony1-general@gborg.postgresql.org http://gborg.postgresql.org/mailman/listinfo/slony1-general ---(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] logging sql from JDBC
Thanks! >-Original Message- >From: Simon Riggs [mailto:[EMAIL PROTECTED] >Sent: Friday, May 27, 2005 11:45 AM >To: David Parker >Cc: pgsql-hackers@postgresql.org >Subject: Re: [HACKERS] logging sql from JDBC > >On Wed, 2005-05-25 at 12:03 -0400, David Parker wrote: >> Could somebody point me at the area of the source where this >decision >> gets made, and/or how difficult it would be to enable this logging? > >This has just been fixed for 8.1, patch recently submitted. > >In the meantime, use p6spy > >Best Regards, Simon Riggs > > > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] logging sql from JDBC
It appears that SQL submited via the latest JDBC driver won't get logged even if log_min_duration_statement is set appropriately. From what I've found in the archives, this is because the driver uses an "extended" version of the protocol. Could somebody point me at the area of the source where this decision gets made, and/or how difficult it would be to enable this logging? Thanks! - DAP----------David Parker Tazz Networks (401) 709-5130
Re: [HACKERS] Strange issue with initdb on 8.0 and Solaris automounts
Will this make it into 8.1?
>-Original Message-
>From: Tom Lane [mailto:[EMAIL PROTECTED]
>Sent: Thursday, January 27, 2005 7:38 PM
>To: Kenneth Lareau
>Cc: David Parker; pgsql-hackers@postgresql.org
>Subject: Re: [HACKERS] Strange issue with initdb on 8.0 and
>Solaris automounts
>
>Kenneth Lareau <[EMAIL PROTECTED]> writes:
>> In message <[EMAIL PROTECTED]>, Tom Lane writes:
>>> Could you truss that and see what it does?
>
>> Here's the relevant truss output from 'mkdir
>/software/postgresql-8.0.0'
>> on my Solaris 9 system:
>
>> 10832: mkdir("/software/postgresql-8.0.0", 0777) Err#89 ENOSYS
>> 10832: stat64("/software/postgresql-8.0.0", 0xFFBFFA38) = 0
>
>> It's doing the stat after the mkdir attempt it seems, and
>coming back
>> with the correct response. Hmm, maybe I should look at the
>Solaris 8
>> code for the mkdir command...
>
>Well, the important point is that the stat does succeed. I'm
>not going to put in anything as specific as a check for
>ENOSYS, but it seems reasonable to try the stat first and
>mkdir only if stat fails.
>I've applied the attached patch.
>
> regards, tom lane
>
>*** src/bin/initdb/initdb.c.orig Sat Jan 8 17:51:12 2005
>--- src/bin/initdb/initdb.cThu Jan 27 19:23:49 2005
>***
>*** 476,481
>--- 476,484
> * this tries to build all the elements of a path to a
>directory a la mkdir -p
> * we assume the path is in canonical form, i.e. uses / as
>the separator
> * we also assume it isn't null.
>+ *
>+ * note that on failure, the path arg has been modified to show the
>+ particular
>+ * directory level we had problems with.
> */
> static int
> mkdir_p(char *path, mode_t omode)
>***
>*** 544,573
> }
> if (last)
> (void) umask(oumask);
>! if (mkdir(path, last ? omode : S_IRWXU |
>S_IRWXG | S_IRWXO) < 0)
> {
>! if (errno == EEXIST || errno == EISDIR)
>! {
>! if (stat(path, &sb) < 0)
>! {
>! retval = 1;
>! break;
>! }
>! else if (!S_ISDIR(sb.st_mode))
>! {
>! if (last)
>! errno = EEXIST;
>! else
>! errno = ENOTDIR;
>! retval = 1;
>! break;
>! }
>! }
>! else
> {
> retval = 1;
> break;
> }
> }
> if (!last)
> *p = '/';
>--- 547,570
> }
> if (last)
> (void) umask(oumask);
>!
>! /* check for pre-existing directory; ok if it's
>a parent */
>! if (stat(path, &sb) == 0)
> {
>! if (!S_ISDIR(sb.st_mode))
> {
>+ if (last)
>+ errno = EEXIST;
>+ else
>+ errno = ENOTDIR;
> retval = 1;
> break;
> }
>+ }
>+ else if (mkdir(path, last ? omode : S_IRWXU |
>S_IRWXG | S_IRWXO) < 0)
>+ {
>+ retval = 1;
>+ break;
> }
> if (!last)
> *p = '/';
>
---(end of broadcast)---
TIP 3: 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] Strange issue with initdb on 8.0 and Solaris automounts
Yes, thanks very much!
- DAP
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Lareau
>Sent: Thursday, January 27, 2005 8:10 PM
>To: Tom Lane
>Cc: Kenneth Lareau; pgsql-hackers@postgresql.org
>Subject: Re: [HACKERS] Strange issue with initdb on 8.0 and
>Solaris automounts
>
>In message <[EMAIL PROTECTED]>, Tom Lane writes:
>>Kenneth Lareau <[EMAIL PROTECTED]> writes:
>>> In message <[EMAIL PROTECTED]>, Tom Lane writes:
Could you truss that and see what it does?
>>
>>> Here's the relevant truss output from 'mkdir
>/software/postgresql-8.0.0'
>>> on my Solaris 9 system:
>>
>>> 10832: mkdir("/software/postgresql-8.0.0", 0777)
>Err#89 ENOSYS
>>> 10832: stat64("/software/postgresql-8.0.0", 0xFFBFFA38) = 0
>>
>>> It's doing the stat after the mkdir attempt it seems, and
>coming back
>>> with the correct response. Hmm, maybe I should look at the
>Solaris 8
>>> code for the mkdir command...
>>
>>Well, the important point is that the stat does succeed. I'm
>not going
>>to put in anything as specific as a check for ENOSYS, but it seems
>>reasonable to try the stat first and mkdir only if stat fails.
>>I've applied the attached patch.
>>
>> regards, tom lane
>
>
>Tom, thank you very much for the patch, it worked like a charm.
>
>
>Ken Lareau
>[EMAIL PROTECTED]
>
>---(end of
>broadcast)---
>TIP 9: the planner will ignore your desire to choose an index
>scan if your
> joining column's datatypes do not match
>
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Strange issue with initdb on 8.0 and Solaris automounts
I tried that, and it just runs into the problem with the first sub dir
it tries to create:
ed9i03:/home/dparker/temp
% initdb -D /home/dparker/temp/testdb
The files belonging to this database system will be owned by user
"dparker".
This user must also own the server process.
The database cluster will be initialized with locale C.
fixing permissions on existing directory /home/dparker/temp/testdb ...
ok
creating directory /home/dparker/temp/testdb/global ... initdb: could
not create directory "/home/dparker": Operation not applicable
initdb: removing contents of data directory "/home/dparker/temp/testdb"
ed9i03:/home/dparker/temp
truss:
chmod("/home/dparker/temp/testdb", 0700)= 0
ok
write(1, " o k\n", 3) = 3
creating directory /home/dparker/temp/testdb/global ... write(1, " c r e
a t i n g d i r".., 56) = 56
umask(0)= 077
umask(077) = 0
mkdir("/home", 0777)Err#17 EEXIST
xstat(2, "/home", 0x08045C20) = 0
mkdir("/home/dparker", 0777)Err#89 ENOSYS
umask(077) = 077
fstat64(2, 0x08045000) = 0
initdbwrite(2, " i n i t d b", 6) = 6
: could not create directory "write(2, " : c o u l d n o t ".., 30)
= 30
/home/dparkerwrite(2, " / h o m e / d p a r k e".., 13) = 13
": write(2, " " : ", 3)= 3
Operation not applicablewrite(2, " O p e r a t i o n n o".., 24)
= 24
- DAP
>-Original Message-
>From: Tom Lane [mailto:[EMAIL PROTECTED]
>Sent: Thursday, January 27, 2005 6:22 PM
>To: David Parker
>Cc: Kenneth Lareau; pgsql-hackers@postgresql.org
>Subject: Re: [HACKERS] Strange issue with initdb on 8.0 and
>Solaris automounts
>
>"David Parker" <[EMAIL PROTECTED]> writes:
>> Did initdb previously just assume the -D path existed, and now it is
>> trying to create the whole path, if necessary?
>
>Pre-8.0 it was using mkdir(1), which might possibly contain
>some weird workaround for this case on Solaris.
>
>I suppose that manually creating the data directory before
>running initdb would also avoid this issue, since the mkdir(2)
>loop is only entered if we don't find the directory in existence.
>
> regards, tom lane
>
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Strange issue with initdb on 8.0 and Solaris automounts
Coincidentally I JUST NOW built 8.0 on Solaris 9, and ran into the same
problem. As they say, "this used to work".
We build databases as part of the build of our product, and I'm looking
into what we need to do to upgrade from 7.4.5, and this was the first
thing I ran into. I hadn't gotten as far as truss yet, so thanks Kenneth
for that extra info.
Did initdb previously just assume the -D path existed, and now it is
trying to create the whole path, if necessary?
- DAP
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Lareau
>Sent: Thursday, January 27, 2005 5:23 PM
>To: pgsql-hackers@postgresql.org
>Subject: [HACKERS] Strange issue with initdb on 8.0 and
>Solaris automounts
>
>Folks,
>
>I ran into an interesting issue when installing PostgreSQL 8.0
>that I'm not sure how to resolve correctly. My system is a
>Sun machine (Blade
>1000) running Solaris 9, with relatively recent patches. After
>install- ing 8.0, I went to run the 'initdb' command and was
>greeted with the
>following:
>
>[delirium:postgres] ~
>(11) initdb -D /software/postgresql-8.0.0/data The files
>belonging to this database system will be owned by user "postgres".
>This user must also own the server process.
>
>The database cluster will be initialized with locale C.
>
>creating directory /software/postgresql-8.0.0/data ... initdb:
>could not create directory "/software/postgresql-8.0.0":
>Operation not applicable
>
>
>The error message was a bit confusing, so I decided to run a
>truss on the process to see what might be happening, and this
>is what I came
>across:
>
>[...]
>8802/1: write(1, " c r e a t i n g d i r".., 62) = 62
>8802/1: umask(0)= 077
>8802/1: umask(077) = 0
>8802/1: mkdir("/software", 0777)
> Err#17 EEXIST
>8802/1: stat64("/software", 0xFFBFC858) = 0
>8802/1: mkdir("/software/postgresql-8.0.0", 0777)
> Err#89 ENOSYS
>[...]
>
>
>The last error in that section, ENOSYS, is very strange, as
>the Solaris manpage for 'mkdir' does not mention it as a
>possible error. One thing to note in this, however, is that
>'/software/postgresql-8.0.0' is not a regular directory, but
>an automount point (which in this case is just a local
>loopback mount). So the indication is that Solaris seems to
>have a bug not in mkdir, but deeper in their VFS code that's
>causing this seemingly strange issue.
>
>Two workarounds for this problem have been found: running
>'initdb' with a directory that's *not* an automount point and
>then moving the 'data'
>directory to its final destination worked fine, along with a
>suggestion from Andrew Dunstan (on the #postgresql IRC
>channel) with using a rela- tive path for the data directory.
>Both were successful in avoiding the issue, but I decided to
>mention this here in case someone felt it might be worth
>looking into to see if the Sun problem can be avoided; I am
>going to notify Sun of their bug, just don't know how long it
>will take them to actually resolve it (if they ever do).
>
>While I can fully understand that a code change here may not
>be desire- able, might some notes in the documentation be
>useful for those who might stumble across the problem as well?
> Just a suggestion...
>
>I hope I gave sufficient information on the problem, though
>I'm always willing to give any clarification needed. Thank
>you for your time.
>
>
>Ken Lareau
>[EMAIL PROTECTED]
>
>---(end of
>broadcast)---
>TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Increasing the length of
How difficult would it be to make the combination log_statement = all log_duration = true just put the duration on the same line as the statement? Then log_min_duration_statement could be used to do the desired log-at-threshold behavior, which certainly seems valuable. You'd need a way to visually/scriptually (?) distinguish those log records, though, I guess. Note that my original post on this was more of a question than an objection - it's entirely possible to sed around having duration and statement on separate lines - I just wanted clarification. Having them on the same line IS handy, however - DAP >-Original Message- >From: Bruce Momjian [mailto:[EMAIL PROTECTED] >Sent: Wednesday, December 01, 2004 11:18 AM >To: Simon Riggs >Cc: David Parker; [EMAIL PROTECTED] >Subject: Re: [HACKERS] Increasing the length of > >Simon Riggs wrote: >> On Tue, 2004-11-30 at 19:32, Bruce Momjian wrote: >> > David Parker wrote: >> > > I've been using "log_min_duration_statement = 0" to get >durations >> > > on all SQL statements for the purposes of performance tuning, >> > > because this logs the duration on the same line as the >statement. >> > > My reading of this TODO is that now >log_min_duration_statement = 0 >> > > would give me the statements but no total duration? >> > >> > Oh, sorry, you are right. I forgot about the duration >part! I got >> > so excited I forgot. >> > >> > TODO item removed. >> >> David's objection was noted, and why I hadn't coded it (yet). >> >> There are currently two ways of getting statement and >duration output, >> which is confusing >> >> You can either >> 1. Individual statements >> - log_statement = all >> - log_duration = true >> - log_line_prefix includes processid >> >> which produces 2 log lines like >> statement: x >> duration: yy >> >> 2. log_min_duration >> log_min_duration_statement=0 >> which produces 1 log line like >> duration: yyy statement: xx >> >> These two things do exactly the same thing, apart from the way the >> output is presented to the user in the log line. >> >> I'd like to change log_min_duration_statement as suggested, but this >> side-effect behaviour of being a better log_statement than >> log_statement kindof gets in the way. It makes me wonder why we have >> log_statement at all. > >We have it so you can look in the log to see currently running >queries rather than just completed queries. > >> We all want to do performance tracing. I'd also like to be able to >> dynamically monitor what is actually happening *now* on the system. >> There is no way right now to monitor for rogue queries, >other than to >> cancel anything that runs more than statement_timeout. Thats >not good >> either, even if it does keep the current behaviour. >> >> My preference would be to do the following: >> - add a script to contrib to process the log file >> - always add processid to log_statement_prefix when both >log_statement >> and log_duration are specified, so you can always tie up the data > >I think our setup is confusing enough. Adding "automatic" >additions seems even more confusing than what we have now. We >could throw a log warning message somehow though. > >-- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, >Pennsylvania 19073 > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Increasing the length of
I've been using "log_min_duration_statement = 0" to get durations on all SQL statements for the purposes of performance tuning, because this logs the duration on the same line as the statement. My reading of this TODO is that now log_min_duration_statement = 0 would give me the statements but no total duration? - DAP >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian >Sent: Tuesday, November 30, 2004 1:20 PM >To: Simon Riggs >Cc: Andrew Sullivan; [EMAIL PROTECTED] >Subject: Re: [HACKERS] Increasing the length of > > >Great idea. Added to TODO: > >* Make log_min_duration_statement output when the duration is >reached rather > than when the statement completes > > This prints long queries while they are running, making >trouble shooting > easier. Also, it eliminates the need for log_statement because it > would now be the same as a log_min_duration_statement of zero. > >--- > > >Simon Riggs wrote: >> On Wed, 2004-11-10 at 22:51, Andrew Sullivan wrote: >> > On Wed, Nov 10, 2004 at 09:52:17PM +, Simon Riggs wrote: >> > > On Wed, 2004-11-10 at 21:48, Richard Huxton wrote: >> > > > >> > > > Isn't that: >> > > > log_min_duration_statement (integer) >> > > >> > > That gets written when a statement completes, not during >execution. >> > >> > I've been following this thread, and I was thinking the >same thing. >> > I wonder how much work it'd be to have another log setting -- say >> > log_statement_after_min_duration (integer) -- which did what Simon >> > wants. That'd more than satisfy my need, for sure. Might >the cost >> > of that be too high, though? >> >> I think this is a great idea. >> >> ...Rather than invent a new GUC, I think this is the solution: >> >> log_min_duration_statement writes to log at end of execution, if >> execution time is greater than that threshold. Let's move that piece >> of code so it is executed as the query progresses. That way, you get >> notified that a problem query is occurring NOW, rather than "it has >> occurred". >> >> The code already has such a timer check, for statement_timeout, in >> backend/storage/lmgr/proc.c. We could reuse this timer to go off at >> log_min_duration_statement and then log query if still >executing. (If >> log_min_duration_statement >= statement_timeout, we would skip that >> step.) We would then reset the timer so that it then goes >off at where >> it does now, at statement_timeout. So, same piece of code, >used twice... >> >> That way you can set up 2 limits, with three bands of actions: >> >> Between 0 and log_min_duration_statement >> - logs nothing >> >> Between log_min_duration_statement and statement_timeout >> - statement written to log, though execution continues... >> >> At statement_timeout >> - statement cancelled >> >> We'd just need a small piece of code to set timer correctly first, >> then another piece to record state change and reset timer >again. Lift >> and drop the existing code from end-of-execution. >> >> This then: >> - solves the *problem query* diagnosis issue, as originally >raised by >> Sean and seconded by myself and Greg >> - makes the answer exactly what Tom proposed - look in the logs >> - doesn't make any changes to the technical innards of UDP and >> pgstats.c >> - no administrative interface changes, just slightly changed >behaviour >> - existing users mostly wouldn't even notice we'd done it... >> >> Thoughts? >> >> Easy enough change to be included as a hot fix for 8.0: no >new system >> code, no new interface code, just same behaviour at different time. >> >> >> -- >> Best Regards, Simon Riggs >> >> >> ---(end of >> broadcast)--- >> TIP 9: the planner will ignore your desire to choose an >index scan if your >> joining column's datatypes do not match >> > >-- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, >Pennsylvania 19073 > >---(end of >broadcast)--- >TIP 9: the planner will ignore your desire to choose an index >scan if your > joining column's datatypes do not match > ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] PostgreSQL on z/OS
I am not currently working on z/OS, and don't have access to a z/OS environment, but I did a little work with getting OpenLDAP ported to z/OS at my previous company. I assume you mean Unix System Services (USS) under z/OS, rather than zLinux. Since zLinux is essentially Suse ported to the Z architecture, I don't imagine there would be major issues there. USS, on the other hand, is a different story. It's "posix compliant", so the basic C stdlib stuff works, and things like shared memory are available, etc. But because it co-exists in a weird way with MVS, there is a lot of extra baggage to worry about, especially in the security area (RACF). In order to get the best performance out of it, you would need to run the server as a "started task", meaning it would be started from the MVS side of the house via JCL. There is also the question of what other open-source/GNU type things the build environment depends on. Here is a list of open-source projects that have been ported to USS available from IBM: http://www.ibm.com/servers/eserver/zseries/zos/unix/redbook/index.html This is a limited set, and most of the packages are some revs back. You're not limited to this set, of course - it just might mean extra porting. And here is a link from the OpenLDAP FAQ posted by the OpenLDAP committer who did the bulk of the porting for us: http://www.openldap.org/faq/data/cache/719.html In general, I found working with USS somewhat unpleasant, but porting postgres should be possible. - DAP >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of David Fetter >Sent: Wednesday, September 01, 2004 12:16 PM >To: PG Hackers >Subject: [HACKERS] PostgreSQL on z/OS > >Folks, > >At Linuxworld Expo/SF, I got a chance to talk a bit with one >Andrew Schmidt of IBM about the possibility of porting >PostgreSQL to z/OS. > >Here's what he asked about. Any z/OS developers in the house >who can address it? > >Cheers, >D > >- Forwarded message from Andrew Schmidt <[EMAIL PROTECTED]> - > >> In mid August, I did make some inquiries about using our ISV >> facilities, but as we do not have for z/OS any 'free' locations, I >> continue to check other avenues. Could you do me a favor >and document >> (doesn't have to be deeply technical) the requirements that >you would >> have on such a facility you would need access to in terms of >software, >> amount of time, duration of usage, that sort of thing. >> >> Am I to take it, by the way, that this is being requested as a free >> service? If you are a Partnerworld for Developers member, we >> certainly have for-fee locations that are available to you. >> >> Regards - > >> - Andrew >> >-- >> --- >> IBM eServer Solution Offering for Linux >> (http://ibm.com/servers/enable/) >http://ibm.com/servers/eserver/zseries/solutions/s390da/linuxpr >oduct.html >> Phone: (845) 435-6134 Fax (845) 432-9132 Tie Line 8-295-6134 >> Building 708 Office 2C3 >> [EMAIL PROTECTED] >> >> US Mail: >> IBM Systems and Technology Group, Dept. Q5CA Mail Station P389 >> 2455 South Road, Poughkeepsie NY 12601-5400 > >- End forwarded message - > >-- >David Fetter [EMAIL PROTECTED] http://fetter.org/ >phone: +1 510 893 6100 mobile: +1 415 235 3778 > >Remember to vote! > >---(end of >broadcast)--- >TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > ---(end of broadcast)--- TIP 8: explain analyze is your friend
