Re: [GENERAL] Performance PLV8 vs PLPGSQL

On Wed, Dec 28, 2016 at 3:15 AM, Tim Uckun wrote: > I have seen various links on the internet which indicate that PLV8 is > significantly faster than PL-PGSQL sometimes an order of magnitude faster. > > Is this uniformly true or is it just in certain circumstances? > > Is

Re: [GENERAL] Performance PLV8 vs PLPGSQL

Yes I use a migrations tool as well. I like ruby so I use either the Sequel migrations or the ActiveRecord migrations depending on the project. That's a great way to work. Having said that I think it might be an interesting thing to do to create the PGAdmin hierarchy of objects on disk. Not the

Re: [GENERAL] Performance PLV8 vs PLPGSQL

The reason that you cannot use git for that is that it was never intended for live data and stuff that resides on a database. That said, I agree with you that all table DDLs and stored procedures should be kept under version control. And in fact I do keep them under VC on my database. How do I

Re: [GENERAL] Performance PLV8 vs PLPGSQL

I have datagrip and it's OK but it doesn't really do everything I want. I don't understand why it doesn't fetch all objects from the database and then put them into the disk in a directory so I can put it all under git and then let me work on them syncing the files back as they change. For

Re: [GENERAL] Performance PLV8 vs PLPGSQL

If you want an IDE, Jetbrains, the makers of great IDEs like IntelliJ, PyCharm. and AppCode, among others, have recently come out with what is arguably the BEST IDE for DBAs, DataGrip. It runs on most major platforms, and is so good that I have bitten the bullet and paid the yearly subscription

Re: [GENERAL] Performance PLV8 vs PLPGSQL

I am not saying the postgres core people should work on an IDE, just that an IDE like thing would be nice. On Fri, Dec 30, 2016 at 12:51 PM, Rob Sargent wrote: > I would hope Postgres core folk take no more than a nanosecond to reject > the idea that they work on an IDE.

Re: [GENERAL] Performance PLV8 vs PLPGSQL

I would hope Postgres core folk take no more than a nanosecond to reject the idea that they work on an IDE. Focus on reading and writing faster and faster ACID all the while. > On Dec 29, 2016, at 5:32 PM, Tim Uckun wrote: > > Honestly I don't even like JS. Having said

Re: [GENERAL] Performance PLV8 vs PLPGSQL

Honestly I don't even like JS. Having said that I am not too crazy about PL-PGSQL either. I am willing to put up with either given that they are supported widely in default installs of postgres in AWS, Linux and MacOSX, As I said before, I think posgres gives a unique and underutilized language

Re: [GENERAL] Performance PLV8 vs PLPGSQL

On 29/12/16 09:12, Francisco Olarte wrote: On Wed, Dec 28, 2016 at 5:53 PM, Jan de Visser wrote: .but the term "impedance mismatch" is at least 25 year old; Much older, I was told it in class at least 32 years ago. as far as I know it was coined _Borrowed_ from

Re: [GENERAL] Performance PLV8 vs PLPGSQL

On 12/29/2016 10:35 AM, Pavel Stehule wrote: 2016-12-29 10:03 GMT+01:00 Tim Uckun >: I think it's awesome that postgres allows you to code in different languages like this. It really is a unique development environment and one that is

Re: [GENERAL] Performance PLV8 vs PLPGSQL

2016-12-29 10:03 GMT+01:00 Tim Uckun : > I think it's awesome that postgres allows you to code in different > languages like this. It really is a unique development environment and one > that is overlooked as a development platform. It would be nice if more > languages were

Re: [GENERAL] Performance PLV8 vs PLPGSQL

2016-12-29 10:04 GMT+01:00 Tim Uckun : > Mostly generating SQL statements to execute. Like for example deciding > which partition to insert into. > Then you don't find any possible performance difference - the query is about 10-100x slower than expression - so the plpgsql

Re: [GENERAL] Performance PLV8 vs PLPGSQL

Mostly generating SQL statements to execute. Like for example deciding which partition to insert into. On Thu, Dec 29, 2016 at 10:00 PM, Pavel Stehule wrote: > > > 2016-12-29 9:23 GMT+01:00 Tim Uckun : > >> I am not doubting the efficacy of stored

Re: [GENERAL] Performance PLV8 vs PLPGSQL

I think it's awesome that postgres allows you to code in different languages like this. It really is a unique development environment and one that is overlooked as a development platform. It would be nice if more languages were delivered in the default package especially lua, V8 and mruby. On

Re: [GENERAL] Performance PLV8 vs PLPGSQL

2016-12-29 9:23 GMT+01:00 Tim Uckun : > I am not doubting the efficacy of stored procs, just wondering which > language is better. From the sound of it string manupilation is slow in > PL-PGSQL but looking at my procs there does seem to be a lot of string > manipulation going

Re: [GENERAL] Performance PLV8 vs PLPGSQL

My recommendation. See them as tools in a toolkit, not a question of what is best. For places where you have SQL statements as primary do SQL or PLPGSQL functions. For places where you are manipulating values (parsing strings for example) use something else (I usually use pl/perl for string

Re: [GENERAL] Performance PLV8 vs PLPGSQL

I am not doubting the efficacy of stored procs, just wondering which language is better. From the sound of it string manupilation is slow in PL-PGSQL but looking at my procs there does seem to be a lot of string manipulation going on so maybe I better do some tests. On Thu, Dec 29, 2016 at 3:02

Re: [GENERAL] Performance PLV8 vs PLPGSQL

On Wed, Dec 28, 2016 at 5:53 PM, Jan de Visser wrote: > .but the term "impedance mismatch" > is at least 25 year old; Much older, I was told it in class at least 32 years ago. > as far as I know it was coined _Borrowed_ from electrical engineering / communication techs.

Re: [GENERAL] Performance PLV8 vs PLPGSQL

On Wednesday, December 28, 2016 6:02:51 AM EST Mike Sofen wrote: > the natural lashup of plpgsql to postgres (I liked Alban’s term, > “impedance”), is a key aspect. Not to deprive Alban of any of his credit, but the term "impedance mismatch" is at least 25 year old; as far as I know it was

Re: [GENERAL] Performance PLV8 vs PLPGSQL

From: Tim Uckun I have seen various links on the internet which indicate that PLV8 is significantly faster than PL-PGSQL sometimes an order of magnitude faster. Is there any benefit to choosing PL-PGSQL? I can’t speak to PLV8. However, I can speak to plpgsql, and

Re: [GENERAL] Performance PLV8 vs PLPGSQL

2016-12-28 10:46 GMT+01:00 Pavel Stehule : > Hi > > 2016-12-28 10:15 GMT+01:00 Tim Uckun : > >> I have seen various links on the internet which indicate that PLV8 is >> significantly faster than PL-PGSQL sometimes an order of magnitude faster. >> >> Is

Re: [GENERAL] Performance PLV8 vs PLPGSQL

Hi 2016-12-28 10:15 GMT+01:00 Tim Uckun : > I have seen various links on the internet which indicate that PLV8 is > significantly faster than PL-PGSQL sometimes an order of magnitude faster. > > Is this uniformly true or is it just in certain circumstances? > It depends on

[GENERAL] Performance PLV8 vs PLPGSQL

I have seen various links on the internet which indicate that PLV8 is significantly faster than PL-PGSQL sometimes an order of magnitude faster. Is this uniformly true or is it just in certain circumstances? Is there any benefit to choosing PL-PGSQL? Is there work going on to make PL-PGSQL more