question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Problems with bytea performance

See original GitHub issue

I originally opened this as part of a knex issue: https://github.com/tgriesser/knex/issues/2052 but was directed here instead.

I have a simple query:

SELECT glb FROM models where assets_id = 16 LIMIT 1;

glb is a bytea column and the value I’m retrieving is 28630077 bytes (~27MB) (models contains a single row in this example). The query takes 13305 ms to run and the Node process (not the DB process) maxes out the CPU while the query is running). If I query for the assets_id column instead of the glb column, it only takes 2 ms.

Running the same query with the same data from the psql command line completes almost immediately:

time psql -A -c "SELECT glb FROM models where assets_id = 16 LIMIT 1;" master postgres > out.glb

real    0m0.679s
user    0m0.000s
sys     0m0.031s

I also tested the same query in pg-native and it completed in ~450ms, but using pg-native isn’t an option for me at this time (though I might have to re-evaluate that depending on where this issue goes).

Here’s the table definition for completeness.

CREATE TABLE public.models
(
  assets_id integer NOT NULL,
  glb bytea NOT NULL,
  CONSTRAINT models_pkey PRIMARY KEY (assets_id),
  CONSTRAINT models_assets_id_foreign FOREIGN KEY (assets_id)
      REFERENCES public.assets (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE CASCADE
)
WITH (
  OIDS=FALSE
);
ALTER TABLE public.models
  OWNER TO postgres;

Finally, I thought maybe it was a performance issue in the type parser, but all of the time is taken up by the query and then the typeParser completes almost instantly at the end.

Am I doing something wrong? Or is there a performance issue with bytea issues? I’d be happy to debug this further myself if someone can point me in the correct direction. Thanks in advance.

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Reactions:4
  • Comments:22 (10 by maintainers)

github_iconTop GitHub Comments

1reaction
brianccommented, May 15, 2017

Thanks for your help y’all! Much appreciated!

1reaction
mramatocommented, May 10, 2017

OK, thanks. I’ll do a pass myself and see if there is anything obvious I can add. Thanks for the help on this by the way.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Performance issues using PostgreSQL 'Bytea' field
I have noticed recently that a table with many rows using a column of 'Bytea' type in PostgreSQL (version does not matter but...
Read more >
Binary data performance in PostgreSQL - CYBERTEC
No special maintenance is necessary. The main disadvantages of bytea are: like all TOASTed data types, there is an absolute length limit of...
Read more >
Slow updates of PostgreSql ByteA fields with just 1KB of data
I've googled for "bytea performance issues" and found, that people have problems with importing like 100MB of data into a table column, ...
Read more >
size of bytea + performance issues - PostgreSQL
Hi everyone,. my first question concerns the the size of a table with a bytea row. In the documentation it says something like...
Read more >
Thread: Performance of ByteA: ascii vs binary
Probably with bytea_output = hex the performance would be less ... but if you test random vs uniform I think the problem is...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found