[HACKERS] PostgreSQL installation
Dear sir/madam, I am from Cambodia. I want to use PostgreSQL. But I am poor of knowledge to install could you please help me give some guide to install PostgreSQL on Solaris 10, Thanks for your respond and value times. Brs, Lyvar Cambodia
[HACKERS] cannot update to the latest CVS sources
Hi, $ cvs update cvs update: Updating src/backend/commands cvs update: [08:32:37] waiting for anoncvs's lock in /projects/cvsroot/pgsql/src/backend/commands cvs update: [08:33:07] waiting for anoncvs's lock in /projects/cvsroot/pgsql/src/backend/commands cvs update: [08:33:37] waiting for anoncvs's lock in /projects/cvsroot/pgsql/src/backend/commands cvs update: [08:34:07] waiting for anoncvs's lock in /projects/cvsroot/pgsql/src/backend/commands cvs update: [08:34:37] waiting for anoncvs's lock in /projects/cvsroot/pgsql/src/backend/commands cvs update: [08:35:07] waiting for anoncvs's lock in /projects/cvsroot/pgsql/src/backend/commands The cvs's lock remains held? Why? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Modifying TOAST_TUPLE_THRESHOLD and TOAST_TUPLE_TARGET?
Guys, I appreciate your intentions to treat this more flexibly in a future release. But I'm not sure I got a reply to my original questions, about the existing 8.3 version: 1. Am I correct in assuming that in my case the TOAST mechanism probably results in a performance hit, not boost, and is there a way to measure this impact? 2. How can I disable TOAST? Only by changing TOAST_TUPLE_THRESHOLD and TOAST_TUPLE_TARGET in the include file and compiling a private version? Thanks, -- Shaul -- View this message in context: http://www.nabble.com/Modifying-TOAST_TUPLE_THRESHOLD-and-TOAST_TUPLE_TARGET--tp23982524p23996728.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with listen_addresses = '*' on 8.4beta2 on AIX
Tom Lane wrote: On Thu, Jun 11, 2009 at 9:50 AM, Tom Lane wrote: Where are we on this? waiting on a patch? Albe? (or should I do it myself?) I thought the proposed patch was just remove the special case for AIX in src/backend/libpq/ip.c. Yes. The only bugs at IBM that are listed as open are IZ43766 = IZ44519, and they should not affect us (I looked through the code). For the record, these result in ai_socktype and ai_protocol being set to zero in the result. All other problems should be fixed in AIX 6.1 ML 02, AIX 5.3 ML 09 and AIX 5.2 ML 09. It's hard to say for AIX 5.1 and AIX 4.3.3 as they are out of support, and bugs that are fixed in current versions may be unfixed there. On the other hand, the bugs may have been introduced later. Thus, for AIX 5.1 and AIX 4.3.3 we should request that the last Maintenance Level be installed (ML 09 for AIX 5.1 and ML 11 for 4.3.3). I am waiting for Merlin's report whether getaddrinfo(3) works on his AIX 4.3.3 after upgrading to ML 11. I'll attach a small C program I wrote for my convenience to test different getaddrinfo calls that occur in PostgreSQL code. After we have word from Merlin, I'd write a patch that changes src/backend/libpq/ip.c and src/frontend/libpq/ip.c to undo the AIX hack and adds documentation to section 15.8.1 that states the recommended fix levels per AIX version. I won't get to do that before Monday though, so if somebody can do it before that, go ahead. Which raises a final question for me: The documentation mentions support from 4.3 on, and there are specific comments for 4.3.2. We can't say anything for versions before 4.3.3, can we? Should we drop versions 4.3.3 even if Merlin reports success for 4.3.3? Yours, Laurenz Albe test_getaddrinfo.c Description: test_getaddrinfo.c -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with listen_addresses = '*' on 8.4beta2 on AIX
On Fri, Jun 12, 2009 at 7:42 AM, Albe Laurenzlaurenz.a...@wien.gv.at wrote: Which raises a final question for me: The documentation mentions support from 4.3 on, and there are specific comments for 4.3.2. We can't say anything for versions before 4.3.3, can we? Should we drop versions 4.3.3 even if Merlin reports success for 4.3.3? 4.3.3 is working fine. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] port to Windows x64
Hi, We trying to port PostgreSQL to Windows x64. It based on Windows 64bit patch which are posted before. http://archives.postgresql.org/pgsql-hackers/2008-07/msg00440.php Is there someone working in progress about it ? This patch works if total activity memory is less than 2GB, but when memory goes over 2GB there is a problem. (eg) in postgresql.conf, set shared_buffes to over 2GB. There are still following problems, I thought. 1. LLP64 pointer operation 2. over 4GB shared memory allocation 3. reattch to shared memory --- 1. LLP64 Currently PostgreSQL use 'long' for pointer calculation. (eg) TYPEALIGN() in src/include/c.h We intend to replace 'long' to 'intptr_t' in such calculation. Todo for this. * check and add typedef 'intptr_t', in configure and port.h * fix 'long' to 'intptr_t' in pointer calculation. Microsoft C++ compiler with /Wp64 option will outputs warning about pointer assignments that losts data. That helps us to locate source code. (the past messages) http://archives.postgresql.org/pgsql-hackers/2008-07/msg00437.php http://archives.postgresql.org/pgsql-hackers/2008-07/msg00081.php http://archives.postgresql.org/pgsql-hackers/2008-07/msg00105.php 2. shared memory Shared buffer allocation function does not care about =4GB memory. # PGSharedMemoryCreate() in src/backend/port/win32_shmem.c We think it can easily to fix. 3. counld not reattach to shared memory problem There is another problem, and that also occurs under Windows 32bit. http://archives.postgresql.org/pgsql-hackers/2009-05/msg00097.php http://archives.postgresql.org/pgsql-hackers/2009-05/msg00144.php Since the last message, I didn't confirm any progress. We don't have good solution for it. We thought that following VirtualAllocEx() method was good, but did somebody try to test ? http://archives.postgresql.org/pgsql-general/2007-08/msg01592.php Thanks. -- Tsutomu Yamada SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cannot update to the latest CVS sources
Fujii Masao wrote: Hi, $ cvs update cvs update: Updating src/backend/commands cvs update: [08:32:37] waiting for anoncvs's lock in /projects/cvsroot/pgsql/src/backend/commands cvs update: [08:33:07] waiting for anoncvs's lock in /projects/cvsroot/pgsql/src/backend/commands cvs update: [08:33:37] waiting for anoncvs's lock in /projects/cvsroot/pgsql/src/backend/commands cvs update: [08:34:07] waiting for anoncvs's lock in /projects/cvsroot/pgsql/src/backend/commands cvs update: [08:34:37] waiting for anoncvs's lock in /projects/cvsroot/pgsql/src/backend/commands cvs update: [08:35:07] waiting for anoncvs's lock in /projects/cvsroot/pgsql/src/backend/commands The cvs's lock remains held? Why? Seems OK from my computer. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cannot update to the latest CVS sources
Bruce Momjian br...@momjian.us wrote: Fujii Masao wrote: $ cvs update cvs update: Updating src/backend/commands cvs update: [08:32:37] waiting for anoncvs's lock in Seems OK from my computer. I'm having the problem. Same directory. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cannot update to the latest CVS sources
Bruce Momjian br...@momjian.us writes: Fujii Masao wrote: The cvs's lock remains held? Why? Seems OK from my computer. Were you checking anoncvs or the master? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cannot update to the latest CVS sources
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Fujii Masao wrote: The cvs's lock remains held? Why? Seems OK from my computer. Were you checking anoncvs or the master? Oh, sorry, I was checking master. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cannot update to the latest CVS sources
On Fri, Jun 12, 2009 at 9:45 AM, Fujii Masaomasao.fu...@gmail.com wrote: Hi, $ cvs update cvs update: Updating src/backend/commands cvs update: [08:32:37] waiting for anoncvs's lock in /projects/cvsroot/pgsql/src/backend/commands cvs update: [08:33:07] waiting for anoncvs's lock in /projects/cvsroot/pgsql/src/backend/commands cvs update: [08:33:37] waiting for anoncvs's lock in /projects/cvsroot/pgsql/src/backend/commands cvs update: [08:34:07] waiting for anoncvs's lock in /projects/cvsroot/pgsql/src/backend/commands cvs update: [08:34:37] waiting for anoncvs's lock in /projects/cvsroot/pgsql/src/backend/commands cvs update: [08:35:07] waiting for anoncvs's lock in /projects/cvsroot/pgsql/src/backend/commands The cvs's lock remains held? Why? Please try now. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cannot update to the latest CVS sources
Dave Page dp...@pgadmin.org wrote: Please try now. It now works for me. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Modifying TOAST_TUPLE_THRESHOLD and TOAST_TUPLE_TARGET?
Shadar shaul...@gmail.com wrote: 1. Am I correct in assuming that in my case the TOAST mechanism probably results in a performance hit, not boost, Possibly, but you didn't give enough information to be sure. One important factor would be how often the table in question has updates or deletes. If those are very frequent, you might find that TOAST improves performance, because it won't have to read as many disk pages to check visibility for the reading transaction. If it is a table with few updates and deletes and you really do always read the array, it might be faster to avoid the out-of-line storage aspect of TOAST. (The compression might still be valuable, if it often squeezes two rows per page rather than one.) and is there a way to measure this impact? Like many performance issues, the only way to be absolutely sure is to benchmark it both ways with a good simulation of your expected load. (Testing one aspect, such as just the SELECTs, in the absence of the modification load you expect, will not really give you good information on this point.) 2. How can I disable TOAST? Only by changing TOAST_TUPLE_THRESHOLD and TOAST_TUPLE_TARGET in the include file and compiling a private version? There have been several suggestions already. If you're going to modify the source to deal with this, you might want to look at the patch I proposed, and consider something like that. Keep in mind that it hasn't been reviewed, it's just a suggestion I threw out there as a possibility, with all the usual use at your own risk caveats. With that patch, you would avoid errors on values which don't fit on a single page, but when values are set for a column flagged with ALTER TABLE SET STORAGE MAIN, they will not be moved out-of-line (into the separate TOAST table) unless the row won't fit in a single page without doing so. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with listen_addresses = '*' on 8.4beta2 on AIX
Albe Laurenz laurenz.a...@wien.gv.at writes: After we have word from Merlin, I'd write a patch that changes src/backend/libpq/ip.c and src/frontend/libpq/ip.c to undo the AIX hack and adds documentation to section 15.8.1 that states the recommended fix levels per AIX version. I won't get to do that before Monday though, so if somebody can do it before that, go ahead. The code change is already made for RC1, but if you want to send in a patch to improve the docs, feel free. I left it with just a vague recommendation to update to the latest fixpack: http://developer.postgresql.org/pgdocs/postgres/installation-platform-notes.html#INSTALLATION-NOTES-AIX regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Modifying TOAST_TUPLE_THRESHOLD and TOAST_TUPLE_TARGET?
2. How can I disable TOAST? Only by changing TOAST_TUPLE_THRESHOLD and TOAST_TUPLE_TARGET in the include file and compiling a private version? There have been several suggestions already. Yes, but other have commented that these (e.g. dropping TOAST table) might not work and even lose data, so I was left confused as to what would work... If you're going to modify the source to deal with this... Again: do I have a choice? I'd rather not touch the code. Thanks, -- Shaul -- View this message in context: http://www.nabble.com/Modifying-TOAST_TUPLE_THRESHOLD-and-TOAST_TUPLE_TARGET--tp23982524p24000355.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL installation
I am from Cambodia. I want to use PostgreSQL. But I am poor of knowledge to install could you please help me give some guide to install PostgreSQL on Solaris 10, (+ to pgsql-general) Try to use the general list for these cases, you could obtain better results ;) The documentation for Solaris are in the site #1, you will find since installation until complex trace rutines. Enjoy it! #1[http://www.sun.com/software/products/postgresql/index.jsp] Regards, -- Emanuel Calvo Franco ArPUG [www.arpug.com.ar] / AOSUG Member www.emanuelcalvofranco.com.ar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with listen_addresses = '*' on 8.4beta2 on AIX
Tom Lane wrote: The code change is already made for RC1, but if you want to send in a patch to improve the docs, feel free. I left it with just a vague recommendation to update to the latest fixpack: http://developer.postgresql.org/pgdocs/postgres/installation-platform-notes.html#INSTALLATION-NOTES-AIX The attached patch states that we support 4.3.3 to 6.1, removes the comment for version 4.3.2 and adds a table of minimum recommended fix levels for AIX. Use all or parts of it as you think fit. Yours, Laurenz Albe aixdoc.patch Description: aixdoc.patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Modifying TOAST_TUPLE_THRESHOLD and TOAST_TUPLE_TARGET?
Shadar shaul...@gmail.com wrote: There have been several suggestions already. Yes, but other have commented that these (e.g. dropping TOAST table) might not work and even lose data, so I was left confused as to what would work... Well, dropping the TOAST table once you have data in it will lose data. The main problem with the techniques which don't involve modifying the source code are that you can't force the column to be stored in-line without getting an error on an attempt to store a value which makes the row too big to fit on a single page. Again: do I have a choice? I'd rather not touch the code. You've got lots of choices. For starters, I'm not at all sure you will even have a performance benefit from inlining the data. You could choose to just let PostgreSQL work the way most people do. A couple options have been mentioned if you are sure your rows will always fit on one page. None of these involve touching the source code. I threw together the patch to give you another option. Touching the code isn't so scary once you get the hang of building from source. Obviously you want test carefully before putting custom code into production. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output
On 6/11/09 10:15 PM, Robert Haas wrote: Here we go, XML and JSON output. You will need to apply explain_refactor-v4.patch and explain_options-v2.patch first, then apply the two patches attached to this message. Wow, cool. Can this work with auto_explain? That's where I see machine-readable being most useful. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with listen_addresses = '*' on 8.4beta2 on AIX
Albe Laurenz laurenz.a...@wien.gv.at writes: The attached patch states that we support 4.3.3 to 6.1, removes the comment for version 4.3.2 and adds a table of minimum recommended fix levels for AIX. Applied with a bit of additional wordsmithing. Thanks! regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output
On Fri, Jun 12, 2009 at 11:47 AM, Josh Berkusj...@agliodbs.com wrote: On 6/11/09 10:15 PM, Robert Haas wrote: Here we go, XML and JSON output. You will need to apply explain_refactor-v4.patch and explain_options-v2.patch first, then apply the two patches attached to this message. Wow, cool. Can this work with auto_explain? That's where I see machine-readable being most useful. The patch does touch contrib/auto_explain, but just enough to make it keep working the same way it does now. I don't think it would be too hard to improve on that, though; I might work on it if I get bored, but I'm hoping someone else will be motivated enough to do that part. :-) How would you go about extracting the XML/JSON bits from the rest of what is in the log file? (apologies if this is a question I should already know the answer to) ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output
How would you go about extracting the XML/JSON bits from the rest of what is in the log file? (apologies if this is a question I should already know the answer to) If you do CSV output, it's in a field. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Documentation: GiST extension implementation
Dimitri Fontaine dfonta...@hi-media.com writes: I've been working some more on this documentation: Applied with some editorialization. It seems to me it could still do with a lot more detail to specify what API the functions are really expected to implement. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Documentation: GiST extension implementation
Hi, Le 12 juin 09 à 21:49, Tom Lane a écrit : Applied with some editorialization. Thanks a lot :) It seems to me it could still do with a lot more detail to specify what API the functions are really expected to implement. I'm sorry I'm not following... I guess you're talking about a better high-level view of things? Like describing GiST itself, the way it's done in the following link, but reduced in one or two paragraphs? http://gist.cs.berkeley.edu/gist1.html I'll be happy to work on improving this documentation some more (but won't be there next week)... Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output
Josh Berkus wrote:
How would you go about extracting the XML/JSON bits from the rest of
what is in the log file? (apologies if this is a question I should
already know the answer to)
If you do CSV output, it's in a field.
And even if it's not, a well formed XML document would be fairly easy to
extract, especially if the root element is well known (e.g. pg:explain
or some such). And if the patch doesn't produce a well-formed XML doc
then it needs work ;-). It might be nice if Robert were to post some
samples of the output.
Quick question: does the patch use formal methods using, say, the DOM
API to build up the XML, or informal methods (like
foo.append('element'); foo.append(content); foo.append('/element'); )
As you can tell, I haven't looked over it yet. But I intend to ;-)
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Documentation: GiST extension implementation
Dimitri Fontaine dfonta...@hi-media.com writes: Le 12 juin 09 à 21:49, Tom Lane a écrit : It seems to me it could still do with a lot more detail to specify what API the functions are really expected to implement. I'm sorry I'm not following... I guess you're talking about a better high-level view of things? Like describing GiST itself, the way it's done in the following link, but reduced in one or two paragraphs? http://gist.cs.berkeley.edu/gist1.html No, we already have that level of detail (some of it word for word in fact); and it's not all that important for opclass authors to know how GIST works anyway. What's bothering me is the fuzziness of the API specifications for the support functions. It's not real clear for example what you have to do to have an index storage type different from the column datatype, and even less clear which type the same() function is comparing. Having some skeletons that execute magic bits of undocumented code is not a substitute for a specification. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output
On Fri, Jun 12, 2009 at 5:13 PM, Andrew Dunstanand...@dunslane.net wrote:
Josh Berkus wrote:
How would you go about extracting the XML/JSON bits from the rest of
what is in the log file? (apologies if this is a question I should
already know the answer to)
If you do CSV output, it's in a field.
And even if it's not, a well formed XML document would be fairly easy to
extract, especially if the root element is well known (e.g. pg:explain or
some such). And if the patch doesn't produce a well-formed XML doc then it
needs work ;-). It might be nice if Robert were to post some samples of the
output.
pgexplain, as it happens... I could post some samples of the
output, but it seems like it might be just as well to let those who
are curious try it for themselves. I'd rather get opinions from
people who care enough to download test than from those who are just
bikeshedding. :-)
Quick question: does the patch use formal methods using, say, the DOM API to
build up the XML, or informal methods (like foo.append('element');
foo.append(content); foo.append('/element'); )
As you can tell, I haven't looked over it yet. But I intend to ;-)
Use the Source, Luke. :-)
But, it's informal methods. I don't see a lot of value in doing it
the other way, though perhaps I could be convinced otherwise. One
thing that's nice about the way it works now is that the only support
function it requires is a basic XML-escaping function, which it turns
out we already have in the PG sources anyway, though not in a quite
usable form (the infrastructure patch deals with the necessary
adjustments). So you can explain (format xml) even if you compile
without --with-libxml.
If you want to see how the actual XML/JSON stuff works, you might want
to start with the last patch in the series (explain_format). If you
want to commit it, a course of action to which I can give my unbiased
endorsement, then you'll want to start with explain_refactor.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output
On Friday 12 June 2009 08:15:17 Robert Haas wrote: Here we go, XML and JSON output. Could you post some examples of how some plans would look in either format? That would help us judge the particulars. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] some of the datatypes only support hashing, while others only support sorting
This errdetail doesn't seem quite right in the following situation: rhaas=# select distinct proacl from pg_proc; ERROR: could not implement DISTINCT DETAIL: Some of the datatypes only support hashing, while others only support sorting. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cannot update to the latest CVS sources
Hi, On Fri, Jun 12, 2009 at 11:18 PM, Kevin Grittnerkevin.gritt...@wicourts.gov wrote: Dave Page dp...@pgadmin.org wrote: Please try now. It now works for me. So do I. Thanks! Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
