Re: [HACKERS] proposal: lob conversion functionality
2013/10/26 Noah Misch n...@leadboat.com On Fri, Oct 25, 2013 at 03:35:05PM +0200, Pavel Stehule wrote: 2013/10/24 Heikki Linnakangas hlinnakan...@vmware.com On 22.10.2013 13:55, Pavel Stehule wrote: 2013/10/21 Noah Mischn...@leadboat.com If you're prepared to change the function names and add the subset-oriented functions, I would appreciate that. here is patch lobj.sgml still refer to the old names. fixed documentation Thanks. I made these noteworthy changes: 1. Fix lo_get(oid) on a LO larger than INT_MAX bytes: raise an error rather than performing a modulo operation on the size. 2. Remove the undocumented ability to pass a negative length to request all bytes up to the end of the LO. substr() also rejects negative lengths. Note that one can get the same effect by passing any length MaxAllocSize. 3. Documentation reshuffling. I placed all the documentation for these functions in the large objects chapter, and I emphasized the new functions over the prospect of calling the older functions (whose primary role is to support client interfaces) from SQL. If this still looks reasonable, I will commit it. it is ok Regards Pavel -- Noah Misch EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] high-dimensional knn-GIST tests (was Re: Cube extension kNN support)
On Thu, Oct 24, 2013 at 3:50 AM, Gordon Mohr gojomo-pg...@xavvy.com wrote: On 9/22/13 4:38 PM, Stas Kelvich wrote: Hello, hackers. Here is the patch that introduces kNN search for cubes with euclidean, taxicab and chebyshev distances. Thanks for this! I decided to give the patch a try at the bleeding edge with some high-dimensional vectors, specifically the 1.4 million 1000-dimensional Freebase entity vectors from the Google 'word2vec' project: I believe the curse of dimensionality is affecting you here. I think it is impossible to get an improvement over sequential scan for 1000 dimensional vectors. Read here: http://en.wikipedia.org/wiki/Curse_of_dimensionality#k-nearest_neighbor_classification Regards Marcin Mańk
Re: [HACKERS] CLUSTER FREEZE
On 10/26/2013 01:20 AM, Josh Berkus wrote: On 10/24/2013 07:19 PM, Tom Lane wrote: In any case, it's very far from obvious to me that CLUSTER ought to throw away information by default, which is what you're proposing. The problem here is that you're thinking of the 1/10 of 1% of our users who have a serious PostgreSQL failure and post something on the lists for help, for which XID forensic information is useful. As opposed to the 99.9% of our users for whom deferred freezing is a performance burden. While I realize that the 0.1% of users are more likely to have contact with you, personally, it's still bad policy for the project. Strong +1 from me. Doing the performant, sensible, low-admin thing by default is really important if you don't want a database that requires a two year training course and a professional DBA to use. Some DB vendors make that part of their business model, but personally at least that's certainly not the direction I'd like to see Pg go in. Autovacuum wrap-around prevention already gets rid of this info, it's not like it's kept forever anyway. Anything that makes the mechanics of bloat and vacuum less visible is a big win as far as I'm concerned. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- 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] dsm use of uint64
On Fri, Oct 25, 2013 at 10:11:41PM -0400, Robert Haas wrote: When I wrote the dynamic shared memory patch, I used uint64 everywhere to measure sizes - rather than, as we do for the main shared memory segment, Size. This now seems to me to have been the wrong decision; I'm finding that it's advantageous to make dynamic shared memory behave as much like the main shared memory segment as is reasonably possible, and using Size facilitates the use of MAXALIGN(), TYPEALIGN(), etc. as well as things like add_size() and mul_size() which are just as relevant in the dynamic shared memory case as they are for the main shared memory segment. Therefore, I propose to apply the attached patch. +1. The simplicity of platform-independent type sizing had some attraction, but not so much to justify this sort of friction with the rest of the system. -- Noah Misch EnterpriseDB 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
[HACKERS] PostgreSQL Service on Windows does not start. ~ is not a valid Win32 application
Hi All, I have found a case that PostgreSQL Service does not start. When it happens, the following error appears. is not a valid Win32 application This failure occurs when the following conditions are true. 1. There is postgres.exe in any directory that contains a space, such as Program Files. e.g.) C:\Program Files\PostgreSQL\bin\postgres.exe 2. A file using the first white space-delimited tokens of that directory as the file name exists, and there is it in the same hierarchy. e.g.) C:\Program //file pg_ctl.exe as PostgreSQL Service creates a postgres process using an absolute path which indicates the location of postgres.exe,but the path is not enclosed in quotation. Therefore,if the above-mentioned conditions are true, CreateProcessAsUser(a Windows Function called by pg_ctl.exe) tries to create a process using the other file such as Program, so the service fails to start. Accordingly, I think that the command path should be enclosed in quotation. I created a patch to fix this failure, So could anyone confirm? Regards, Naoya --- Naoya Anzai Engineering Department NEC Soft, Ltd. E-Mail: anzai-na...@mxu.nes.nec.co.jp --- pg_ctl.c.patch Description: pg_ctl.c.patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
