Sv: Re: pspg - psql pager

users. > It is now on apt.postgresql.org   http://postgr.es/m/e1efc37-0007rv...@atalia.postgresql.org And will be in Debian Unstable soon as it is in the NEW queue for manual review from Debian's FTP Master.    https://ftp-master.debian.org/new/pspg_0.5-1.html Regards, Marco     Coolio!   -- Andreas Joseph Krogh  

Sv: Sv: Re: Query is over 2x slower with jit=on

På onsdag 18. april 2018 kl. 18:26:03, skrev Andreas Joseph Krogh < andr...@visena.com <mailto:andr...@visena.com>>: På onsdag 18. april 2018 kl. 17:50:55, skrev Andres Freund <and...@anarazel.de <mailto:and...@anarazel.de>>: On 2018-04-18 17:35:31 +0200, Andreas Joseph

Sv: Better Upgrades

have logical decoding for DCL (GRANT/REVOKE)   - Need to add support for decoding LargeObjects.   -- Andreas Joseph Krogh

Logical decoding currently not usable for all due to lack of LargeObject-support

The lack of LargeObject-support makes it unusable for installations using it.   Any plans to support LOs in logical decoding so we can replicate databases using them?   -- Andreas Joseph Krogh

Sv: Re: Logical decoding currently not usable for all due to lack of LargeObject-support

På torsdag 16. august 2018 kl. 13:38:54, skrev Andres Freund mailto:and...@anarazel.de>>: Hi, On 2018-08-16 13:31:14 +0200, Andreas Joseph Krogh wrote: > The lack of LargeObject-support makes it unusable for installations using it. >   > Any plans to support LOs in logical dec

Re: Query is over 2x slower with jit=on

I compiled with whatever switches LLVM that comes with Ubuntu 18.04 is built with, and without debugging or assertions.   -- Andreas Joseph Krogh

Sv: Re: JIT compiling with LLVM v12

v10.   -- Andreas Joseph Krogh

Sv: Re: Query is over 2x slower with jit=on

guably a new feature, although I don't find that a terribly convincing position. Greetings, Andres Freund   Just to be clear; The query really runs slower (wall-clock time), it's not just the timing.   -- Andreas Joseph Krogh

Re: Query is over 2x slower with jit=on

På onsdag 22. august 2018 kl. 20:52:05, skrev Andres Freund mailto:and...@anarazel.de>>: On 2018-08-22 19:51:12 +0200, Andreas Joseph Krogh wrote: > I thought JITing of prepared queries happended once (in "prepare") No, it happens when the first JITed function is executed.

Sv: Re: Query is over 2x slower with jit=on

På onsdag 22. august 2018 kl. 18:51:55, skrev Andres Freund mailto:and...@anarazel.de>>: On 2018-08-22 18:39:18 +0200, Andreas Joseph Krogh wrote: > Just to be clear; The query really runs slower (wall-clock time), it's not > just the timing. I bet it's not actually running slow

Sv: Re: Query is over 2x slower with jit=on

På torsdag 23. august 2018 kl. 09:14:56, skrev Andreas Joseph Krogh < andr...@visena.com <mailto:andr...@visena.com>>: På torsdag 23. august 2018 kl. 03:00:42, skrev Jonathan S. Katz < jk...@postgresql.org <mailto:jk...@postgresql.org>>: > On Aug 22, 2018, at 7:

Sv: Re: WIP: Covering + unique indexes.

På lørdag 07. april 2018 kl. 22:02:08, skrev Teodor Sigaev <teo...@sigaev.ru <mailto:teo...@sigaev.ru>>: Thanks to everyone, pushed.   Rock!   -- Andreas Joseph Krogh  

Query is over 2x slower with jit=on

UTER JOIN'ed.   On v10 the query executes in: Execution time: 1159.628 ms   So v11 (with jit=off) is about 25% faster (due to parallel hash-join I think), which is nice!   What's the deal with jit making it slower?   -- Andreas Joseph Krogh

Sv: Re: Query is over 2x slower with jit=on

På onsdag 18. april 2018 kl. 17:50:55, skrev Andres Freund <and...@anarazel.de <mailto:and...@anarazel.de>>: On 2018-04-18 17:35:31 +0200, Andreas Joseph Krogh wrote: > With jit=on: > https://explain.depesz.com/s/vYB > Planning Time: 0.336 ms >  JIT: >   Function

Sv: Re: ERROR: Aggref found in non-Agg plan node (introducesd in commit 3bf05e096b9f8375e640c5d7996aa57efd7f240c)

På tirsdag 27. februar 2018 kl. 12:16:42, skrev Jeevan Chalke < jeevan.cha...@enterprisedb.com <mailto:jeevan.cha...@enterprisedb.com>>: Hi,   On Tue, Feb 27, 2018 at 3:46 PM, Andreas Joseph Krogh <andr...@visena.com <mailto:andr...@visena.com>> wrote: $subject   The quer

Sv: Re: Requesting advanced Group By support

ally-dependent columns from the aggregation. regards   Too bad this doesn't:   create table t (id int NOT NULL UNIQUE, b int, c int, d int);   explain select * from t group by id, b, c; ERROR:  column "t.d" must appear in the GROUP BY clause or be used in an aggregate function LINE 1: explain select * from t group by id, b, c;     -- Andreas Joseph Krogh ​

Re: ERROR: failed to add item to the index page

På tirsdag 30. april 2019 kl. 16:27:05, skrev Andreas Joseph Krogh < andr...@visena.com <mailto:andr...@visena.com>>: [snip] Yep, happens without --with-llvm also. I'll try to load only the necessary table(s) to reproduce. I have a 1.4GB dump (only one table) which reliably reproduce

Re: ERROR: failed to add item to the index page

På tirsdag 30. april 2019 kl. 18:48:45, skrev Peter Geoghegan mailto:p...@bowt.ie>>: On Tue, Apr 30, 2019 at 9:47 AM Tom Lane wrote: > Andreas Joseph Krogh writes: > > I have a 1.4GB dump (only one table) which reliably reproduces this error. > > Shall I share it off-

Sv: Re: ERROR: failed to add item to the index page

eneral, but you're not that... So please > try to write readable mails for the PG lists. > > Greetings, > > Andres Freund ACK. -- Andreas Joseph Krogh

Sv: Re: ERROR: failed to add item to the index page

on't push a fix for this today. -- Peter Geoghegan Nice, thanks! -- Andreas Joseph Krogh

Re: ERROR: failed to add item to the index page

Re: Sv: subject issue...). But it has tons of benefits CRM- and usage-wise so I prefer to use it. But - how use text/plain these days:-) -- Andreas Joseph Krogh

ERROR: failed to add item to the index page

to happen) -- Andreas Joseph Krogh

Sv: Sv: Re: Sv: Re: ERROR: failed to add item to the index page

På tirsdag 30. april 2019 kl. 16:03:04, skrev Andreas Joseph Krogh < andr...@visena.com <mailto:andr...@visena.com>>: På tirsdag 30. april 2019 kl. 15:53:50, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > I built with this: make distclean &

Sv: Re: ERROR: failed to add item to the index page

På tirsdag 30. april 2019 kl. 15:43:16, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > With master (3dbb317d32f4f084ef7badaed8ef36f5c9b85fe6) I'm getting this: > visena=# CREATE INDEX origo_email_part_hdrvl_value_idx ON > public.origo_email_part_he

Sv: Re: Sv: Re: ERROR: failed to add item to the index page

På tirsdag 30. april 2019 kl. 15:53:50, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > I built with this: make distclean && ./configure > --prefix=$HOME/programs/postgresql-master --with-openssl --with-llvm && make -j > 8 install-worl

Re: ERROR: failed to add item to the index page

; and avoids unsigned underflow. Thanks! -- Andreas Joseph Krogh

ERROR: attribute number 6 exceeds number of columns 5

column end_timestamp timestamp ; alter table access add column tsrange TSRANGE NOT NULL GENERATED ALWAYS AS (tsrange(start_timestamp, end_timestamp, '[)')) STORED ; -- Andreas Joseph Krogh error.sql Description: application/sql

Sv: Just for fun: Postgres 20?

This project already tried that: https://www.postgresql.org/docs/12/history.html#HISTORY-POSTGRES95 <https://www.postgresql.org/docs/12/history.html#HISTORY-POSTGRES95> Didn't last long... -- Andreas Joseph Krogh

Re: Minimal logical decoding on standbys

for notifying. Attached is the rebased version. Will this patch enable logical replication from a standby-server? -- Andreas Joseph Krogh

Re: Minimal logical decoding on standbys

model works with a publication on a physical standby. This patch is focussed on providing a way to continue logical replication *after* the standby is promoted as master. Thanks for clarifying. -- Andreas Joseph Krogh

Re: color by default

are colored/emphasized imo. Much like colored output from grep/diff; We humans have colored vision for a reason. -- Andreas Joseph Krogh

ERROR: could not determine which collation to use for string comparison

ECT nullif(lower(coalesce($1, '')) || lower(coalesce($2, '')), '') $$ LANGUAGE SQL IMMUTABLE; select * from person pers ORDER BY concat_lower(pers.firstname, pers.lastname)ASC; === -- Andreas Joseph Krogh

Re: EXPLAIN(VERBOSE) to CTE with SEARCH BREADTH FIRST fails

d type has not been registered FWIW; I saw this Open Item was set to fixed, but I'm still getting this error in 388726753b638fb9938883bdd057b2ffe6f950f5 -- Andreas Joseph Krogh

Re: EXPLAIN(VERBOSE) to CTE with SEARCH BREADTH FIRST fails

d this patch claim to fix it. regards, tom lane Ok, sorry for the noise. -- Andreas Joseph Krogh

Re: CHECK Constraint Deferrable

ith NULLs then UPDATE the “NOT NULLs” later. “Rewrite the ORM” is not an option for most of us… -- Andreas Joseph Krogh