Column lookup in a row performance

Hi PostgreSQL Community, I am learning deeply how tuples are organized and column values are accessed in different databases. As far as undertood postgres does not store all column positions in a tuple (e.g. in header or footer). In contrast MySQL InnoDB stores column lengths in a record header [1

Re: Materialized view breaks pg_restore

On 3/21/19 8:15 PM, David Wheeler wrote: Hi, We’re regularly having an issue when restoring dumps of our databases like this [exec] CREATE DATABASE "testRestore"; [exec] pg_restore: [archiver (db)] Error while PROCESSING TOC: [exec] pg_restore: [archiver (db)] Error from TOC

Materialized view breaks pg_restore

Hi, We’re regularly having an issue when restoring dumps of our databases like this [exec] CREATE DATABASE "testRestore"; [exec] pg_restore: [archiver (db)] Error while PROCESSING TOC: [exec] pg_restore: [archiver (db)] Error from TOC entry 15728; 0 43798 MATERIALIZED VIEW DATA f

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

Thomas Munro writes: > On Thu, Mar 21, 2019 at 5:07 PM Tom Lane wrote: >> Thomas Munro writes: >>> If someone out there is not enabling any of that stuff >>> because their system doesn't like threads, they can use >>> --disable-thread-safety to avoid the effects of this change. >> No, that's no

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

On Thu, Mar 21, 2019 at 5:07 PM Tom Lane wrote: > Thomas Munro writes: > > If someone out there is not enabling any of that stuff > > because their system doesn't like threads, they can use > > --disable-thread-safety to avoid the effects of this change. > > No, that's nonsense; --disable-thread-

RE: Postgres 9.6 Slave Creation

Hello, a little follow up... We attempted the same method one more time with no success. Today we used pg_basebackup. Successfully created slave. Eric

Re: Performance of ByteA: ascii vs binary

On 3/21/19 6:49 AM, Tom Lane wrote: "Peter J. Holzer" writes: On 2019-03-20 13:20:57 +0100, Thomas Güttler wrote: Strange. I saw a big difference. What did you test? I tested inserts. The graph with the quantiles was for selects. Hmm, so there are two different code paths being considered

Re: Performance of ByteA: ascii vs binary

"Peter J. Holzer" writes: > On 2019-03-20 13:20:57 +0100, Thomas Güttler wrote: >> Strange. I saw a big difference. >> What did you test? >> I tested inserts. > The graph with the quantiles was for selects. Hmm, so there are two different code paths being considered here -- the OP is apparently

Re: Performance of ByteA: ascii vs binary

On 2019-03-20 13:20:57 +0100, Thomas Güttler wrote: > > > Am 19.03.19 um 20:37 schrieb Peter J. Holzer: > > On 2019-03-18 15:33:17 +0100, Thomas Güttler wrote: > > > I did some benchmarking and in my setup there was major > > > performance difference. > > > > > > I tested a ByteA column. > > >

SV: to_timestamp function

Thanks for fast reply! I'll forward the answer to my developers. kr Mikael Gustavsson Från: Tom Lane [t...@sss.pgh.pa.us] Skickat: den 20 mars 2019 17:33 Till: Gustavsson Mikael Kopia: pgsql-general@lists.postgresql.org Ämne: Re: to_timestamp function Gu