Re: WARNING: could not flush dirty data: Function not implemented

On Sun, Sep 02, 2018 at 04:31:18PM -0700, Andres Freund wrote: > Please note that nobody has verified that postgres works correctly via > the emulation stuff MS is doing. There is a native version of postgres > for windows however, and that is tested (and exercised by a lot of > installations).

Re: WARNING: could not flush dirty data: Function not implemented

Tom Lane writes: > Ravi Krishna writes: >>> Whee ... so you get to cope with all the bugs/idiosyncrasies of three >>> operating system layers, not just one. I concur that running Postgres >>> in the underlying Windows O/S is probably a much better idea. > >> Me too, but this is purely for

Re: WARNING: could not flush dirty data: Function not implemented

Tom Lane writes: > Andres Freund writes: >> On 2018-09-02 19:29:49 -0400, Tom Lane wrote: >>> If this is on Ubuntu, I don't understand why you're talking >>> about Windows. > >> The OP said "Ubuntu 18.04 as Windows bash" - so I assume this is >> postgres compiled as a linux binary is running

Re: Sv: Re: How to get shorter SERVER_VERSION in psql-prompt?

## Rob Sargent (robjsarg...@gmail.com): > > Ugh. (So this is coming from "configure --with-extra-version" stuff) > Does that also diddle the value of "server_version_num"? No, that's still integer-format (it's unchanged and you can cast it straight into INTEGER). Gruss, Christoph -- Spare

Sv: Re: Sv: Re: How to get shorter SERVER_VERSION in psql-prompt?

På mandag 03. september 2018 kl. 23:43:46, skrev Rob Sargent < robjsarg...@gmail.com >: On 09/03/2018 03:42 PM, Alvaro Herrera wrote: > On 2018-Sep-03, Andreas Joseph Krogh wrote: > >> select setting as server_version from pg_settings where name = >>

Re: Sv: Re: How to get shorter SERVER_VERSION in psql-prompt?

On 09/03/2018 03:42 PM, Alvaro Herrera wrote: On 2018-Sep-03, Andreas Joseph Krogh wrote: select setting as server_version from pg_settings where name = 'server_version'; ┌──┐ │  server_version  │ ├──┤ │

Re: Sv: Re: How to get shorter SERVER_VERSION in psql-prompt?

On 2018-Sep-03, Andreas Joseph Krogh wrote: > select setting as server_version from pg_settings where name = > 'server_version'; > ┌──┐ > │  server_version  │ > ├──┤ > │ 10.5 (Ubuntu 10.5-1.pgdg18.04+1) │ >

Sv: Re: How to get shorter SERVER_VERSION in psql-prompt?

På mandag 03. september 2018 kl. 23:34:48, skrev Christoph Moench-Tegeder < c...@burggraben.net >: ## Andreas Joseph Krogh (andr...@visena.com): > This results in this verver_version: > 10.5 (Ubuntu 10.5-1.pgdg18.04+1) >    > Is it possible to adjust this somehow

Sv: Re: How to get shorter SERVER_VERSION in psql-prompt?

På mandag 03. september 2018 kl. 23:03:10, skrev Alvaro Herrera < alvhe...@2ndquadrant.com >: On 2018-Sep-03, Andreas Joseph Krogh wrote: > Hi all, I'm using the Ubuntu-packages and have this in my .psqlrc: >   > \set PROMPT1 '%[%033[35m%]%n@%m:%>%[%033[0m%]

Re: How to get shorter SERVER_VERSION in psql-prompt?

## Andreas Joseph Krogh (andr...@visena.com): > This results in this verver_version: > 10.5 (Ubuntu 10.5-1.pgdg18.04+1) >   > Is it possible to adjust this somehow so it outputs only "10.5"? On Debian/Ubuntu, all version strings are somewhat extended. Luckily, with the power of SQL we're not

Re: How to get shorter SERVER_VERSION in psql-prompt?

On 2018-Sep-03, Andreas Joseph Krogh wrote: > Hi all, I'm using the Ubuntu-packages and have this in my .psqlrc: >   > \set PROMPT1 '%[%033[35m%]%n@%m:%>%[%033[0m%] %:server_version: > %[%033[32m%]%/%[%033[0m%]%R%# ' >   > This results in this verver_version: > 10.5 (Ubuntu 10.5-1.pgdg18.04+1)

How to get shorter SERVER_VERSION in psql-prompt?

Hi all, I'm using the Ubuntu-packages and have this in my .psqlrc:   \set PROMPT1 '%[%033[35m%]%n@%m:%>%[%033[0m%] %:server_version: %[%033[32m%]%/%[%033[0m%]%R%# '   This results in this verver_version: 10.5 (Ubuntu 10.5-1.pgdg18.04+1)   Is it possible to adjust this somehow so it outputs only

Re: very slow largeobject transfers through JDBC

Thanks, 1) we'll try to move stuff out from LOBs 2) we might raise a PR for the JDBC driver Mate On Mon, 3 Sep 2018, 19:35 Dave Cramer, wrote: > > > On Mon, 3 Sep 2018 at 13:00, Mate Varga wrote: > >> More precisely: when fetching 10k rows, JDBC driver just does a large >> bunch of socket

Re: WARNING: could not flush dirty data: Function not implemented

Dmitri Maziuk wrote: > Tom Lane wrote: >> Ravi Krishna writes: Whee ... so you get to cope with all the bugs/idiosyncrasies of three operating system layers, not just one. I concur that running Postgres in the underlying Windows O/S is probably a much better idea. >> >>> Me too,

Re: very slow largeobject transfers through JDBC

On Mon, 3 Sep 2018 at 13:00, Mate Varga wrote: > More precisely: when fetching 10k rows, JDBC driver just does a large > bunch of socket reads. With lobs, it's ping-pong: one read, one write per > lob... > > Ok, this is making more sense. In theory we could fetch them all but since they are

Re: WARNING: could not flush dirty data: Function not implemented

On Mon, 03 Sep 2018 09:58:57 -0400 Tom Lane wrote: > Ravi Krishna writes: > >> Whee ... so you get to cope with all the bugs/idiosyncrasies of three > >> operating system layers, not just one. I concur that running Postgres > >> in the underlying Windows O/S is probably a much better idea. >

Re: very slow largeobject transfers through JDBC

More precisely: when fetching 10k rows, JDBC driver just does a large bunch of socket reads. With lobs, it's ping-pong: one read, one write per lob... On Mon, Sep 3, 2018 at 6:54 PM Mate Varga wrote: > So I have detailed profiling results now. Basically it takes very long > that for each blob,

Re: very slow largeobject transfers through JDBC

So I have detailed profiling results now. Basically it takes very long that for each blob, the JDBC driver reads from the socket then it creates the byte array on the Java side. Then it reads the next blob, etc. I guess this takes many network roundtrips. On Mon, Sep 3, 2018 at 5:58 PM Dave

Re: timestamp arithmetics in C function

Hello all, unfortunately, I have so far not received a reply to my question below. I am well aware that no one has an obligation to reply; I was just wondering whether I phrased my question badly or whether there is anything else I could do to improve it. Thanks for your help and best wishes,

Re: very slow largeobject transfers through JDBC

On Mon, 3 Sep 2018 at 10:48, Mate Varga wrote: > That's 1690 msec (1.69 seconds, and that is how long it takes to fetch 20k > (small-ish) rows without LOBs (LOBs are a few lines below on the screenshot) > that sound high as well! Something isn't adding up.. Dave Cramer

Re: very slow largeobject transfers through JDBC

That's 1690 msec (1.69 seconds, and that is how long it takes to fetch 20k (small-ish) rows without LOBs (LOBs are a few lines below on the screenshot) On Mon, Sep 3, 2018 at 4:40 PM Dave Cramer wrote: > the one you have highlighted ~1.69ms > > Dave Cramer > > da...@postgresintl.com >

Re: very slow largeobject transfers through JDBC

the one you have highlighted ~1.69ms Dave Cramer da...@postgresintl.com www.postgresintl.com On Mon, 3 Sep 2018 at 10:38, Mate Varga wrote: > Which frame do you refer to? > > On Mon, Sep 3, 2018 at 3:57 PM Dave Cramer wrote: > >> Not sure why reading from a socket is taking 1ms ? >> >> Dave

Re: very slow largeobject transfers through JDBC

Which frame do you refer to? On Mon, Sep 3, 2018 at 3:57 PM Dave Cramer wrote: > Not sure why reading from a socket is taking 1ms ? > > Dave Cramer > > da...@postgresintl.com > www.postgresintl.com > > > On Mon, 3 Sep 2018 at 09:39, Mate Varga wrote: > >> Hi, >> >> https://imgur.com/a/ovsJPRv

Re: WARNING: could not flush dirty data: Function not implemented

Ravi Krishna writes: >> Whee ... so you get to cope with all the bugs/idiosyncrasies of three >> operating system layers, not just one. I concur that running Postgres >> in the underlying Windows O/S is probably a much better idea. > Me too, but this is purely for learning and I am much more

Re: very slow largeobject transfers through JDBC

Not sure why reading from a socket is taking 1ms ? Dave Cramer da...@postgresintl.com www.postgresintl.com On Mon, 3 Sep 2018 at 09:39, Mate Varga wrote: > Hi, > > https://imgur.com/a/ovsJPRv -- I've uploaded the profiling info (as an > image, sorry). It seems this is a JDBC-level problem. I

Re: WARNING: could not flush dirty data: Function not implemented

> > Whee ... so you get to cope with all the bugs/idiosyncrasies of three > operating system layers, not just one. I concur that running Postgres > in the underlying Windows O/S is probably a much better idea. Me too, but this is purely for learning and I am much more use to Linux stack then

Re: very slow largeobject transfers through JDBC

Hi, https://imgur.com/a/ovsJPRv -- I've uploaded the profiling info (as an image, sorry). It seems this is a JDBC-level problem. I understand that the absolute timing is not meaningful at all because you don't know how large the resultset is, but I can tell that this is only a few thousands rows

Re: WARNING: could not flush dirty data: Function not implemented

Andres Freund writes: > On 2018-09-02 19:29:49 -0400, Tom Lane wrote: >> If this is on Ubuntu, I don't understand why you're talking >> about Windows. > The OP said "Ubuntu 18.04 as Windows bash" - so I assume this is > postgres compiled as a linux binary is running on MS's new-ish linux >

Re: WARNING: could not flush dirty data: Function not implemented

>That means that the linux emulation by microsoft isn't good enough. You >can work around it by setting checkpoint_flush_after=0 and >wal_writer_flush_after=0. bgwriter_flush_after = 0# measured in pages, 0 disables backend_flush_after = 0# measured in pages, 0

Re: very slow largeobject transfers through JDBC

Hey, we'll try to test this with pure JDBC versus hibernate. Thanks! On Mon, Sep 3, 2018 at 11:48 AM Dave Cramer wrote: > > > On Mon, 3 Sep 2018 at 03:55, Mate Varga wrote: > >> Basically there's a class with a byte[] field, the class is mapped to >> table T and the byte field is annotated

Re: very slow largeobject transfers through JDBC

On Mon, 3 Sep 2018 at 03:55, Mate Varga wrote: > Basically there's a class with a byte[] field, the class is mapped to > table T and the byte field is annotated with @Lob so it goes to the > pg_largeobject table. > Ah, so hibernate is in the mix. I wonder if that is causing some challenges ?

Re: very slow largeobject transfers through JDBC

Basically there's a class with a byte[] field, the class is mapped to table T and the byte field is annotated with @Lob so it goes to the pg_largeobject table. The DB is on separate host but relatively close to the app, and I can reproduce the problem locally as well. One interesting bit is that