Live data from Hacker News

PostgresJs: PostgreSQL client for Node.js and Deno

github.com

41–50 of 148 posts

Re: PostgresJs: PostgreSQL client for Node.js and Deno

#41
post #35
post #27

reposting my comment on its benchmarks: On what makes it postgres.js faster, from author himself: > it seems Postgres.js is actually faster than, not only pg, but of any driver out-there - https://github.com/porsager/postgres/discussions/627 - https://porsager.github.io/imdbench/sql.html

What does fast actually mean specifically? The slow bit isn't the client, surely?

Sorry, but you’ve been fooled by the web and functional programmers propaganda against performance.

Also, what the author seems to mean is that this is faster than specific python, js and go clients.

Anyway. At the IO boundary, there’s a lot of syscalls (polls, reads, mallocs especially), and how you manage syscalls can be a major performance sticking point. Additionally, serialization and deserialization can have performance pitfalls as well (do you raw dog offsets or vtable next next next). How you choose to move memory around when dealing with the messages impacts performance greatly (ie, creating and destroying lots of objects in hot loops rather than reusing objects).

The slow bit can definitely be the client.

Re: PostgresJs: PostgreSQL client for Node.js and Deno

#43
post #13
post #9

>> Prepared statements will automatically be created for any queries where it can be inferred that the query is static What does this mean in practice? Like, actual prepared statements are created against the DB session if there are no bound variables, even if that query is only made once? If so, it's an interesting but highly opinionated approach...

If you're using parameterized queries, then you _have_ to use PostgreSQL's "Extended Query" flow, which is what most people would think of as a "prepared statement". This is hardly opinionated. But normally, you use an unnamed prepared statement and/or portal, which PG will clean up for you, essentially only letting you have one of those per session (what we think of as a connection). I agree that sentence didn't mak…

In most SQL databases, once you have a connection handle, you can allocate an arbitrary number of statement handles, and each SQL "statement" can be executed independently, has an associated query, parameters, a result set, and so on.

It is entirely ordinary with an API like that to prepare a statement, bind parameters and columns, and execute and fetch the results. You can then reuse a statement in its prepared state, but usually with different parameter values, as many times as you want within the same session.

The performance advantage of doing this for non-trivial queries is so substantial that many databases have a server side parse cache that is checked for a match even when a client has made no attempt to reuse a statement as such. That is easier if you bind parameters, but it is possible for a database to internally treat all embedded literals as parameters for caching purposes.

Re: PostgresJs: PostgreSQL client for Node.js and Deno

#44
post #27

reposting my comment on its benchmarks: On what makes it postgres.js faster, from author himself: > it seems Postgres.js is actually faster than, not only pg, but of any driver out-there - https://github.com/porsager/postgres/discussions/627 - https://porsager.github.io/imdbench/sql.html

Clarification: it is measured against these clients (not C/C++/etc)

```

        EdgeDB (Python)
        PostgreSQL (Pyhton, psycopg2)
        PostgreSQL (Python, asyncpg)
        PostgreSQL (Node.js, postgres)
        PostgreSQL (Node.js, pg)
        PostgreSQL (Go, pgx)
```

Re: PostgresJs: PostgreSQL client for Node.js and Deno

#45
post #35

Earlier quoted context omitted.

What does fast actually mean specifically? The slow bit isn't the client, surely?

It means once again JavaScript is faster than rust.

That is still unknown, as the Rust implementation is not on the benchmarks page.

Re: PostgresJs: PostgreSQL client for Node.js and Deno

#47
post #35
post #27

reposting my comment on its benchmarks: On what makes it postgres.js faster, from author himself: > it seems Postgres.js is actually faster than, not only pg, but of any driver out-there - https://github.com/porsager/postgres/discussions/627 - https://porsager.github.io/imdbench/sql.html

What does fast actually mean specifically? The slow bit isn't the client, surely?

It’s web scale end to end
Post reply on HN