Re: [GENERAL] B-tree index on a VARCHAR(4000) column
Ron Johnson writes: > Based on LENGTH(offending_column), none of the values are more than 144 > bytes in this 44.2M row table. Even though VARCHAR is, by definition, > variable length, are there any internal design issues which would make > things more efficient if it were dropped to, for example, VARCHAR(256)? No. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] B-tree index on a VARCHAR(4000) column
On Thu, Sep 7, 2017 at 10:48 PM, Ron Johnson wrote: > Hi, > > v 9.2.7 > > Based on LENGTH(offending_column), none of the values are more than 144 > bytes in this 44.2M row table. Even though VARCHAR is, by definition, > variable length, are there any internal design issues which would make > things more efficient if it were dropped to, for example, VARCHAR(256)? > > (I don't have access to the source code or to development boxes, so can't > just test this on my own.) Just use TEXT :-). Realizing that obsessing about column lengths was a giant waste of time and energy for zero useful benefit that I've ever observed was a transformational moment for me. Also, please apply bugfix upgrades :-). merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] SAP Application deployment on PostgreSQL
Hi All, We have multiple SAP applications running on Oracle as backend and looking for an opportunity to migrate from Oracle to PostgreSQL. Has anyone ever deployed SAP on PostgreSQL community edition? Is PostgreSQL community involved in any future road-map of SAP application deployment on PostgreSQL? Thanks chiru
Re: [GENERAL] SAP Application deployment on PostgreSQL
On 9/8/2017 12:34 PM, chiru r wrote: We have multiple SAP applications running on Oracle as backend and looking for an opportunity to migrate from Oracle to PostgreSQL. Has anyone ever deployed SAP on PostgreSQL community edition? Is PostgreSQL community involved in any future road-map of SAP application deployment on PostgreSQL? Does SAP support PostgreSQL ? -- john r pierce, recycling bits in santa cruz -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] [HACKERS] SAP Application deployment on PostgreSQL
On 8 September 2017 at 15:34, chiru r wrote: > We have multiple SAP applications running on Oracle as backend and looking > for an opportunity to migrate from Oracle to PostgreSQL. Has anyone ever > deployed SAP on PostgreSQL community edition? > > Is PostgreSQL community involved in any future road-map of SAP application > deployment on PostgreSQL? > > Thanks > chiru This has been asked about on SAP's forum, and that's the most appropriate place, in that their applications are very much database-specific. https://archive.sap.com/discussions/thread/1941255 I imagine that it would be a "broadly interesting" idea to run R/3 against PostgreSQL, but, as observed in the discussion thread, the "SAP kernel" is very much NOT database-agnostic. The work that would need to be done to do so would require considerable work on the part of SAP AG, and I'd be somewhat surprised to see them do it. Recall that once upon a time, SAP AG acquired the sources for ADABAS-D, renamed it SAP-DB, and, for a while, made it available as "open source." At the time, it appeared that this was some sort of corporate gamesmanship relating to a vendor selling what one might call "Product O". SAP AG presumably spent a fair bit of effort (and money) establishing that port for some of their products. (I imagine that a port to run R/3 on PostgreSQL might be easier/simpler than running it on SAP-DB, but that's just me imagining...) They subsequently drew the code back to be proprietary, and have released several versions of MaxDB since. I'd be curious as to reasons to expect that SAP AG would want to do a PostgreSQL port. (No doubt other ex-BASIS consultants would also be interested!) -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] B-tree index on a VARCHAR(4000) column
On Fri, Sep 8, 2017 at 6:57 AM Tom Lane wrote: > Ron Johnson writes: > > Based on LENGTH(offending_column), none of the values are more than 144 > > bytes in this 44.2M row table. Even though VARCHAR is, by definition, > > variable length, are there any internal design issues which would make > > things more efficient if it were dropped to, for example, VARCHAR(256)? > > No. > > So the declarative column length has no bearing on memory grants during plan generation/execution?
Re: [GENERAL] Aquameta 0.1 - Request for reviews, contributors
Here's a review comment. Just one for now. Looking at the meta module, I see things like this: execute 'select (count(*) = 1) from ' || quote_ident((row_id::meta.schema_id).name) || '.' || quote_ident((row_id::meta.relation_id).name) || ' where ' || quote_ident((row_id.pk_column_id).name) || ' = ' || quote_literal(row_id.pk_value) into answer; I recently learned what I find to be a better idiom: execute format( $q$ select exists (select * from %1$I.%2$I where %3$I = %4$L); $q$, -- interpolated arguments here (row_id::meta.schema_id).name, (row_id::meta.relation_id).name, (row_id.pk_column_id).name, row_id.pk_value into answer; That is, PostgreSQL has extended string literal syntax where you can use $stuff$ instead of single-quotes, and that makes it much easier to write dynamic (generated for EXECUTE) SQL. In particular, because your $EDITOR [generally] won't recognize this, syntax highlighting for the $quoted$ code will work as expected! This is better not only because it's more concise, easier to line-wrap, and easier on the eyes, but also because you get to use format(). I suspect using format() makes it harder to forget to quote something appropriately -- harder to accidentally create a SQL injection vulnerability. I usually use argument numbering (%$I) instead of referring to the positionally (%I, %L, %s) because it helps a lot whenever I need to refer to one of them multiple times. Of course, this is just a matter of style, but I strongly feel that this is the superior style (at least I find or stumble into a better style), especially when you have several layers of trigger functions creating more trigger functions, as you can easily nest $foo$-quoted string literals by having different quote forms for each level. Also, I used exists() instead of count(*) = 1 -- that's just my personal preference, and a less defensible style matter (it is more verbose...). Nico -- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
