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 there any benefit to choo
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
dat
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
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
exampl
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
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. Focus on reading and wri
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 that I am not too crazy
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
pl
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 electrical engineering /
On 12/29/2016 10:35 AM, Pavel Stehule wrote:
2016-12-29 10:03 GMT+01:00 Tim Uckun mailto:timuc...@gmail.com>>:
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 develo
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 delivered in the defau
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 should be good.
More y
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 procs, just wondering which
>> language is bette
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 T
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 on so maybe I better
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 mani
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
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.
It is used to highl
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 coined
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 s
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 this uniformly true or is it just in certain
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 usage
>
> Is there a
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
23 matches
Mail list logo
