Re: [GENERAL] Build in function to verify email addresses

e convenient to have datatypes for. Being an open-source project I guess one must show initiative and start a discussion on -hackers to see what interesst there's in having one in core. I for one hope there will be.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 90

Re: [GENERAL] PG-10 + ICU and abbreviated keys

På tirsdag 14. november 2017 kl. 00:44:11, skrev Peter Geoghegan mailto:p...@bowt.ie>>: On Mon, Nov 13, 2017 at 2:05 PM, Andreas Joseph Krogh wrote: > When sorting on text, we're usually doing so using an multi-column index, like for instance "CREATE INDEX xxx ON my_tab

Re: [GENERAL] PG-10 + ICU and abbreviated keys

På mandag 13. november 2017 kl. 22:28:40, skrev Peter Geoghegan mailto:p...@bowt.ie>>: On Mon, Nov 13, 2017 at 12:48 PM, Andreas Joseph Krogh wrote: > Thanks. As the person that worked on abbreviated keys, I'd like to hear about how you get with this. How much faster is it for

Re: [GENERAL] PG-10 + ICU and abbreviated keys

should be quite a bit of debug output from that that specifically mentions abbreviated keys.   Thanks.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

Re: [GENERAL] PG-10 + ICU and abbreviated keys

På mandag 13. november 2017 kl. 21:40:47, skrev Peter Geoghegan mailto:p...@bowt.ie>>: On Mon, Nov 13, 2017 at 11:48 AM, Andreas Joseph Krogh wrote: > Ok, so I have to explicitly specify like this: > > create table test(id serial primary key, name varchar collate "nb_NO

Re: [GENERAL] PG-10 + ICU and abbreviated keys

På mandag 13. november 2017 kl. 19:07:53, skrev Peter Geoghegan mailto:p...@bowt.ie>>: On Mon, Nov 13, 2017 at 12:27 AM, Andreas Joseph Krogh wrote: > In PG-10, with ICU enabled, is abbreviated keys now enabled? Yes. ICU will use abbreviated keys on every platform, including Window

[GENERAL] PG-10 + ICU and abbreviated keys

Hi.   In PG-10, with ICU enabled, is abbreviated keys now enabled?   If so, using locale=nb_NO.UTF-8, do I have to use a ICU-specific locale to take advantage of abbreviated keys?   Thanks.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:a

Re: [GENERAL] database size changed after restoring using pg_restore

so did a few more databases using the same steps and they all appeared to be smaller. Is that normal? Yep.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

[GENERAL] OR-clause support for indexes

Hi.   There was a while ago a proposed patch for adding $subject; https://commitfest.postgresql.org/8/454/   Is this being worked on? Any progress in btree-support? -- Andreas Joseph Krogh

[GENERAL] Storing LOs outside the database and having a proper cleanup-mechanism to prevent dangling files

anup job can know the difference between such an INSERT-entry in origo_email_message_file_operation caused by ROLLBACK and and INSERT-entry caused by an in-progress insertEmail() operation.   Does anyone have a robust mechanism for cleaning up files in such scenarios?    Thanks.   -- Andre

Re: [GENERAL] Configure Qt Creator to work with PostgreSQL to extensions development

På søndag 25. juni 2017 kl. 23:02:32, skrev Adrian Klaver < adrian.kla...@aklaver.com <mailto:adrian.kla...@aklaver.com>>: On 06/25/2017 01:34 PM, Andreas Joseph Krogh wrote: > På søndag 25. juni 2017 kl. 17:04:02, skrev Adrian Klaver > mailto:adrian.kla...@aklaver.com>>:

Re: [GENERAL] Configure Qt Creator to work with PostgreSQL to extensions development

nment for developing PG-extentions, not linking Qt in from an extention.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

Re: [GENERAL] pglogical vs. built-in logical replication in pg-10

ing with large objects and streaming to clients (JDBC). The only solution (I've found) which doesn't explode in memory-usage is using LOs (OIDs). Note that we're dealing with multi-gigabytes objects, which need to be "transactional safe" (hence stored in the DB).   --

Re: [GENERAL] pglogical vs. built-in logical replication in pg-10

successfully using logical decoding, correct?     > > I wish PG in some future version will address these quirks so one can operate on LOs more smoothly. You're welcome to help...   Every time issues arise regarding LOs there seems to be little interest to improve matters, and if it do

Re: [GENERAL] pglogical vs. built-in logical replication in pg-10

På torsdag 22. juni 2017 kl. 15:25:20, skrev Achilleas Mantzios < ach...@matrix.gatewaynet.com <mailto:ach...@matrix.gatewaynet.com>>: On 22/06/2017 13:38, Andreas Joseph Krogh wrote: På torsdag 22. juni 2017 kl. 11:43:02, skrev Achilleas Mantzios < ach...@matrix.gatewaynet.

Re: [GENERAL] pglogical vs. built-in logical replication in pg-10

På torsdag 22. juni 2017 kl. 11:43:02, skrev Achilleas Mantzios < ach...@matrix.gatewaynet.com <mailto:ach...@matrix.gatewaynet.com>>: On 22/06/2017 11:21, Andreas Joseph Krogh wrote: Hi.   1. Why should one prefer built-in logical replication in pg-10 to pglogical, does it do anythi

[GENERAL] pglogical vs. built-in logical replication in pg-10

pglogical replicate large objects? I cannot find any notes about large-objects under "Limitations and Restrictions":  https://www.2ndquadrant.com/en/resources/pglogical/pglogical-docs/   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <ma

[GENERAL] OR-clause support for indexes

e you made any progress making it work for btree?   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>

[GENERAL] How to include BIGINT-column in RUM-index sorted by timestamp

his indicates that the folder_id column, which is part of the index, isn't actually "part of the index", meaning it's not used in the index for some reason.   Can you tell me how to craft an index so that folder_id = ANY ('{44965,2470520}'::bigint[]) is part of t

Re: [GENERAL] Upgrading postgresql minor version

ge-repo. Maybe you'll have more luck asking that other places than a PG-mailing-list. -- Andreas Joseph Krogh  

Re: [GENERAL] Upgrading postgresql minor version

of failure just to replace them back. Is it doable? How?   What about just re-installing the previous version the same way you installed the "patch-release"-version? -- Andreas Joseph Krogh  

Re: [GENERAL] RUM-index and support for storing BIGINT as part of a tsvector+timestamp

Ping...   Any feedback is welcome, thanks.   På torsdag 12. januar 2017 kl. 13:13:34, skrev Andreas Joseph Krogh < andr...@visena.com <mailto:andr...@visena.com>>: Hi PostgresPro-guys.   I've asked this before but didn't get any response, so I'll try again. I know

Re: [GENERAL] Searching array for multiple items

ou give an example with definition of index and explain-plan?   It would be interesting to see how this performs vs. contrib/intarray.   Thanks.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

[GENERAL] RUM-index and support for storing BIGINT as part of a tsvector+timestamp

p often is't enough because often there is some other dimention which is *very* relevant to limit the results (like what folder, or account, to search for email-messages in, instead of searching for all in the system).   Thanks.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +

Re: [GENERAL] Question slow query

ified);   Am I missing something?    Yes, you've not shown us: 1. The query 2. The schema 3. Complete EXPLAIN-output   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

Re: [GENERAL] join_collapse_limit = 14

På lørdag 07. januar 2017 kl. 18:25:42, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > På lørdag 07. januar 2017 kl. 17:48:49, skrev Tom Lane <mailto:t...@sss.pgh.pa.us>>: >  If you've got just one problem query, it might be worth your ti

Re: [GENERAL] join_collapse_limit = 14

På lørdag 07. januar 2017 kl. 17:48:49, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > I wonder; In general, is there any downside of having join_collapse_limit = 14 > on modern hardware (32 cores, 64GB RAM), and geqo_threshold=16 ? > I'm aw

[GENERAL] join_collapse_limit = 14

s and performance was acceptable again.   I wonder; In general, is there any downside of having join_collapse_limit = 14 on modern hardware (32 cores, 64GB RAM), and geqo_threshold=16 ? I'm aware of it increasing planning-time, but is this really an issue in practice?   Thanks.   -- Andreas Joseph

Re: [GENERAL] Er Data Modeller for PostgreSQL

//www.jetbrains.com/datagrip/   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

Re: [GENERAL] Replacing an existing unique constraint (not UNIQUE INDEX) with primary key

På tirsdag 20. desember 2016 kl. 11:42:56, skrev Achilleas Mantzios < ach...@matrix.gatewaynet.com <mailto:ach...@matrix.gatewaynet.com>>: On 20/12/2016 12:27, Andreas Joseph Krogh wrote: På tirsdag 20. desember 2016 kl. 11:02:27, skrev Achilleas Mantzios < ach...@matrix.gatewaynet.

Re: [GENERAL] Replacing an existing unique constraint (not UNIQUE INDEX) with primary key

På tirsdag 20. desember 2016 kl. 11:02:27, skrev Achilleas Mantzios < ach...@matrix.gatewaynet.com <mailto:ach...@matrix.gatewaynet.com>>: On 20/12/2016 11:43, Andreas Joseph Krogh wrote: [snip] BEGIN; ALTER TABLE person ADD CONSTRAINT person_pk PRIMARY KEY (entity_id); alter table

[GENERAL] Replacing an existing unique constraint (not UNIQUE INDEX) with primary key

OUP BY person.id which now should use GROUP BY person.entity_id, and not having to also list all other columns selected from the person-table.   How do I proceed with this?   Thanks.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>

Re: [GENERAL] Index size

but the 2016 Jaguar XF MPG gets 24 mpg. -- Melvin Davidson I reserve the right to fantasize.  Whether or not you wish to share my fantasy is entirely up to you.   Samuel, Please note that the accepted convention in this forum is to bottom post. Please do not top post.   The accepted convention in this forum is to not have purple signature:-)   -- Andreas Joseph Krogh  

Re: [GENERAL] Full text search randomly not working for short prefixes?

e problem with "no" seems to be the same.   One can always specify 'simple' as the config, eliminating any "stop-wprd smartness":   andreak=> select to_tsquery('simple', 'a:*');   to_tsquery   'a':* (1 row)   -- Andreas Joseph Krogh

Re: [GENERAL] Incorrect information about GIN-index in RUM's docs

På tirsdag 15. november 2016 kl. 08:48:37, skrev Oleg Bartunov < obartu...@gmail.com <mailto:obartu...@gmail.com>>:     On Tue, Nov 15, 2016 at 10:37 AM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: This item isn't valid, is it?   * There isn't phrase

[GENERAL] Incorrect information about GIN-index in RUM's docs

search was introduced, this isn't really true, or am I missing something?   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>

[GENERAL] Question about RUM's TODO-list

AND folder_id = ANY( ARRAY[2,3]::BIGINT[]) ORDER BY received_timestamp DESC LIMIT 10;   Thanks.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>

Re: [GENERAL] which work memory parameter is used for what?

På onsdag 09. november 2016 kl. 15:54:13, skrev Adrian Klaver < adrian.kla...@aklaver.com <mailto:adrian.kla...@aklaver.com>>: On 11/08/2016 06:45 PM, Andreas Joseph Krogh wrote: > På onsdag 09. november 2016 kl. 03:02:54, skrev John R Pierce > mailto:pie...@hogranch.com>

Re: [GENERAL] which work memory parameter is used for what?

enance_work_mem is used by vacuum and create index operations (including implicit index creation such as add foreign key).   There is no such thing in PG.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

Re: [GENERAL] Exclude pg_largeobject form pg_dump

+                dopt.outputBlobs = false; +                break;     Then this IF sets it back to TRUE:   +    if (dopt.include_everything && !dopt.schemaOnly && !dopt.outputBlobs)          dopt.outputBlobs = true;     ...making it impossible to turn off dumping of blobs.   -- Andr

[GENERAL] Parallel pg_dump/restore and LOs

is working.   Are there some plans to make dumping large tables (typically LOs) benefit from parallelism?   Thanks.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>

Re: [GENERAL] Exclude pg_largeobject form pg_dump

t getting this in master is of course the best.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

Re: [GENERAL] Exclude pg_largeobject form pg_dump

På søndag 23. oktober 2016 kl. 19:15:17, skrev Andreas Joseph Krogh < andr...@visena.com <mailto:andr...@visena.com>>: På søndag 23. oktober 2016 kl. 17:06:57, skrev Guillaume Lelarge < guilla...@lelarge.info <mailto:guilla...@lelarge.info>>: 2016-03-08 21:06 GMT+01

Re: [GENERAL] Exclude pg_largeobject form pg_dump

På søndag 23. oktober 2016 kl. 17:06:57, skrev Guillaume Lelarge < guilla...@lelarge.info <mailto:guilla...@lelarge.info>>: 2016-03-08 21:06 GMT+01:00 Andreas Joseph Krogh mailto:andr...@visena.com>>: På tirsdag 08. mars 2016 kl. 21:03:01, skrev David G. Johnston mailto:david.g.

Re: [GENERAL] pg_upgrade not able to cope with pg_largeobject being in a different tablespace

På tirsdag 18. oktober 2016 kl. 12:39:03, skrev Magnus Hagander < mag...@hagander.net <mailto:mag...@hagander.net>>:     On Thu, Oct 13, 2016 at 7:35 AM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På torsdag 13. oktober 2016 kl. 16:09:34, skrev Bruce Momjian mailt

Re: [GENERAL] pg_upgrade not able to cope with pg_largeobject being in a different tablespace

På torsdag 13. oktober 2016 kl. 16:09:34, skrev Bruce Momjian mailto:br...@momjian.us>>: On Thu, Oct 13, 2016 at 10:14:08AM +0200, Andreas Joseph Krogh wrote: > I would assume that having pg_largeobject in a separate tablespace is more and > more common these days, having real-

[GENERAL] pg_upgrade not able to cope with pg_largeobject being in a different tablespace

velopment of pg_upgrade to cope with this configuration or somehow motivate to getting this issue fixed?   Would any of the PG-companies (2ndQ, EDB, PgPro) take a stab at this?   Any feedback welcome, thanks.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>

Re: [GENERAL] Updated RUM-index and support for bigint as part of index

gle Drive link on your email   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

Re: [GENERAL] ON CONFLICT does not support deferrable unique constraints

På onsdag 24. august 2016 kl. 18:36:16, skrev Francisco Olarte < fola...@peoplecall.com <mailto:fola...@peoplecall.com>>: On Wed, Aug 24, 2016 at 6:26 PM, Scott Marlowe wrote: > On Wed, Aug 24, 2016 at 6:05 AM, Andreas Joseph Krogh >> Are there any plans to lift this restr

[GENERAL] ON CONFLICT does not support deferrable unique constraints

Hope some -hackers read this...   Are there any plans to lift this restriction?   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>

Re: [GENERAL] Postgres Pain Points 2 ruby / node language drivers

ght make sense depending on how much control you have on your DB, domain-model, code, developers etc.   I don't have any pointers describing this separation tho, try asking Mr. Google, that's what I'd do.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909

Re: [GENERAL] Postgres Pain Points 2 ruby / node language drivers

e when evaluating ORMs or having an opinion about them. Being in the latter, I more understand you concerns.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

Re: [GENERAL] Postgres Pain Points 2 ruby / node language drivers

På fredag 12. august 2016 kl. 10:33:19, skrev Chris Travers < chris.trav...@gmail.com <mailto:chris.trav...@gmail.com>>:     On Fri, Aug 12, 2016 at 9:59 AM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På fredag 12. august 2016 kl. 05:27:42, skrev Chris Travers

Re: [GENERAL] Postgres Pain Points 2 ruby / node language drivers

På fredag 12. august 2016 kl. 05:27:42, skrev Chris Travers < chris.trav...@gmail.com <mailto:chris.trav...@gmail.com>>:     On Thu, Aug 11, 2016 at 10:20 PM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På torsdag 11. august 2016 kl. 19:13:08, skrev support

Re: [GENERAL] Updated RUM-index and support for bigint as part of index

På torsdag 11. august 2016 kl. 19:13:10, skrev Artur Zakirov < a.zaki...@postgrespro.ru <mailto:a.zaki...@postgrespro.ru>>: On 07.08.2016 11:05, Andreas Joseph Krogh wrote: > På søndag 07. august 2016 kl. 08:27:06, skrev Oleg Bartunov > mailto:obartu...@gmail.com>>: >

Re: [GENERAL] Postgres Pain Points 2 ruby / node language drivers

X or framework Y popus up doesn't mean the PG-project should maintain drivers for them or support them.   So - yes, it would be great if all the drivers for all languages would be made as reliable and clearly documented as the most supported ones.   -- Andreas Joseph Krogh CTO / Partner

Re: [GENERAL] Updated RUM-index and support for bigint as part of index

11-20 15:41:04.936    200744 | 66655 | 2013-01-28 21:47:44.561   1445927 |    888665 | 2015-09-29 00:26:56    123671 | 83509 | 2012-11-21 14:16:26.448   1129928 | 66658 | 2015-05-09 08:39:14.128 (10 rows)   Neither are ordered by received_timestamp   Can you explain how to get OR

Re: [GENERAL] Updated RUM-index and support for bigint as part of index

På lørdag 06. august 2016 kl. 20:54:32, skrev Artur Zakirov < a.zaki...@postgrespro.ru <mailto:a.zaki...@postgrespro.ru>>: Hello,   2016-08-02 21:08 GMT+03:00 Andreas Joseph Krogh mailto:andr...@visena.com>>:  The ORDER BY part seems strange; It seems one has to find a value &qu

[GENERAL] Updated RUM-index and support for bigint as part of index

is this correct?   It would be great if the docs explained this.   I really miss the opportunity to include a BIGINT as part of the index, so that the WHERE-clause could be like this:   WHERE del.fts_all @@ to_tsquery('simple', 'andreas&kr') AND del.folder_id IN (1 ,2,3)   Having t

Re: [GENERAL] Enquiry

on.   Thanks Mohammed Abdul Azeem   It would make it easier for us to help you if you asked a specific question.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

Re: [GENERAL] Updated RUM?

På mandag 27. juni 2016 kl. 13:20:03, skrev Oleg Bartunov mailto:obartu...@gmail.com>>:     On Fri, Jun 24, 2016 at 2:36 PM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: Hi.   @PostgresPro; Will there be any updates to the rum git-repo any time soon?   Sure.     I under

[GENERAL] Updated RUM?

s you plan to implement (for equalty and sorting). Will there be some kind of btree_rum like there is for btree_gin, to add RUM-support for the types there exists Btree-support for?   Thanks.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com &l

Re: [GENERAL] Question about RUM-index

På fredag 17. juni 2016 kl. 15:47:08, skrev Oleg Bartunov mailto:obartu...@gmail.com>>:     On Fri, Jun 17, 2016 at 3:52 PM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På fredag 17. juni 2016 kl. 13:53:34, skrev Oleg Bartunov mailto:obartu...@gmail.com>>:     On Fr

Re: [GENERAL] Question about RUM-index

g 16. juni 2016 kl. 00:50:45, skrev Jeff Janes mailto:jeff.ja...@gmail.com>>: On Wed, Jun 15, 2016 at 3:56 AM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: Hi.   First; Is this the correct forum to ask questions about the Postgres Pro's new RUM-index?   If not, please poi

Re: [GENERAL] Question about RUM-index

På torsdag 16. juni 2016 kl. 00:50:45, skrev Jeff Janes mailto:jeff.ja...@gmail.com>>: On Wed, Jun 15, 2016 at 3:56 AM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: Hi.   First; Is this the correct forum to ask questions about the Postgres Pro's new RUM-index?   If not

Re: [GENERAL] Question about RUM-index

På onsdag 15. juni 2016 kl. 15:27:32, skrev David G. Johnston < david.g.johns...@gmail.com <mailto:david.g.johns...@gmail.com>>: On Wed, Jun 15, 2016 at 6:56 AM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: Hi.   First; Is this the correct forum to ask questions about

[GENERAL] Question about RUM-index

have "folder_id" as part of the RUM-index so that I can search inan array of folders using the index, AND have the whole result sorted by "sent"-timestamp also using the RUM-index.   In the (limited) documentation sorting using timestamp is done like this:   ORDER BY

Re: [GENERAL] Slides for PGCon2016; "FTS is dead ? Long live FTS !"

p of the rum:-)   It's not easy to fix this. We don't want rum depends on  btree_gin, so probably the easiest way is to have separate operator <=> in rum.   +1 for separate operator!   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.co

Re: [GENERAL] Slides for PGCon2016; "FTS is dead ? Long live FTS !"

s.pdf>     Please, download new version of slides. I added CREATE INDEX commands in examples.   Great!   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

Re: [GENERAL] Slides for PGCon2016; "FTS is dead ? Long live FTS !"

grespro/rum/issues/1   Would be cool to see this fixed so I actually could have a sip of the rum:-)   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

Re: [GENERAL] Slides for PGCon2016; "FTS is dead ? Long live FTS !"

På lørdag 28. mai 2016 kl. 23:59:55, skrev Oleg Bartunov mailto:obartu...@gmail.com>>:     On Thu, May 26, 2016 at 11:26 PM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: Hi.   Any news about when slides for $subject will be available?   I submitted slides to pgcon site, bu

[GENERAL] Slides for PGCon2016; "FTS is dead ? Long live FTS !"

Hi.   Any news about when slides for $subject will be available?   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>

Re: [GENERAL] index on ILIKE/LIKE - PostgreSQL 9.2

På torsdag 12. mai 2016 kl. 10:05:01, skrev Andreas Joseph Krogh < andr...@visena.com <mailto:andr...@visena.com>>: [snp] I created this test:   create table ja_jobs(id bigserial primary key, title varchar not null, clientid bigint not null, time_job bigint not null);

Re: [GENERAL] index on ILIKE/LIKE - PostgreSQL 9.2

På torsdag 12. mai 2016 kl. 09:57:58, skrev Andreas Joseph Krogh < andr...@visena.com <mailto:andr...@visena.com>>: På torsdag 12. mai 2016 kl. 02:30:33, skrev Lucas Possamai < drum.lu...@gmail.com <mailto:drum.lu...@gmail.com>>: Hi there!   I've got a simple but s

Re: [GENERAL] index on ILIKE/LIKE - PostgreSQL 9.2

gint you have to cast the value to bigint for btree_gin to use it (note that this isn't necessary if you use a prepared statement):   SELECT DISTINCT title           FROM ja_jobs WHERE title ILIKE '%RYAN WER%'         and clientid = 31239::bigint  AND time_job > 1457826264   

Re: [GENERAL] "Keyed" sequence?

tp://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram   Then you can do: "id" bigint NOT NULL DEFAULT insta5.next_id(),   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

Re: [GENERAL] Initdb --data-checksums by default

  To make certain garantees that data is by default durable.   What I'm saying is that everything is a compromise, cost/benefit. The universe might explode tomorrow but the chances are slim, so no use preparing for it. Those caring enough probably use checksums, battery-packed RAID etc.   -

Re: [GENERAL] Initdb --data-checksums by default

På onsdag 20. april 2016 kl. 11:02:31, skrev Alex Ignatov < a.igna...@postgrespro.ru <mailto:a.igna...@postgrespro.ru>>:   On 20.04.2016 11:40, Andreas Joseph Krogh wrote: På onsdag 20. april 2016 kl. 10:33:14, skrev Alex Ignatov < a.igna...@postgrespro.ru <mailto:a.igna...@postg

Re: [GENERAL] Initdb --data-checksums by default

'll write to hackers.   -1 on changing the default.   10^15 ~= 1000 TB, which isn't very common yet. Those having it probably are aware of the risk and have enabled checksums already.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

Re: [GENERAL] How to build docs from master?

På mandag 11. april 2016 kl. 15:05:06, skrev Artur Zakirov < a.zaki...@postgrespro.ru <mailto:a.zaki...@postgrespro.ru>>: On 11.04.2016 15:27, Andreas Joseph Krogh wrote: > Hi all. > I have installed PG (master) from git, but it seems the docs are not > built issuing "

[GENERAL] How to build docs from master?

*** [all] Error 2 make[1]: Leaving directory '/home/andreak/dev/postgresql/doc' GNUmakefile:17: recipe for target 'docs' failed make: *** [docs] Error 2     Any hints?   Thanks.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>

Re: [GENERAL] Multi-row constraints, how to avoid unnecessary trigger execution?

7;s updated multiple times within the same transaction, which my suggestion specifically avoids.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

Re: [GENERAL] Multi-row constraints, how to avoid unnecessary trigger execution?

HEN (NEW.t_updated)EXECUTE PROCEDURE index_email_3_tf();   Hope this helps   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

Re: [GENERAL] Exclude pg_largeobject form pg_dump

På tirsdag 08. mars 2016 kl. 21:03:01, skrev David G. Johnston < david.g.johns...@gmail.com <mailto:david.g.johns...@gmail.com>>: On Tue, Mar 8, 2016 at 9:45 AM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På tirsdag 08. mars 2016 kl. 17:38:04, skrev J

Re: [GENERAL] Exclude pg_largeobject form pg_dump

På tirsdag 08. mars 2016 kl. 17:38:04, skrev Joshua D. Drake < j...@commandprompt.com <mailto:j...@commandprompt.com>>: On 03/08/2016 08:02 AM, Andreas Joseph Krogh wrote: > På tirsdag 08. mars 2016 kl. 16:57:01, skrev Tom Lane <mailto:t...@sss.pgh.pa.us>>: > >   

Re: [GENERAL] Exclude pg_largeobject form pg_dump

På tirsdag 08. mars 2016 kl. 17:10:43, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > P�� tirsdag 08. mars 2016 kl. 16:54:19, skrev Adrian Klaver < > adrian.kla...@aklaver.com <mailto:adrian.kla...@aklaver.com>>: >  Off hand I would say y

Re: [GENERAL] Exclude pg_largeobject form pg_dump

På tirsdag 08. mars 2016 kl. 16:57:01, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > What I'm looking for is "inverse -b" in an otherwise complete dump. Any plans > to add that? [ shrug... ]  Nobody ever asked for it before. regards,

Re: [GENERAL] Exclude pg_largeobject form pg_dump

På tirsdag 08. mars 2016 kl. 16:54:19, skrev Adrian Klaver < adrian.kla...@aklaver.com <mailto:adrian.kla...@aklaver.com>>: On 03/08/2016 07:46 AM, Andreas Joseph Krogh wrote: > På tirsdag 08. mars 2016 kl. 16:30:36, skrev Tom Lane <mailto:t...@sss.pgh.pa.us>>: >

Re: [GENERAL] Exclude pg_largeobject form pg_dump

På tirsdag 08. mars 2016 kl. 16:30:36, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > P�� tirsdag 08. mars 2016 kl. 15:43:37, skrev Adrian Klaver < > adrian.kla...@aklaver.com <mailto:adrian.kla...@aklaver.com>>: >  Do you care about not

Re: [GENERAL] Exclude pg_largeobject form pg_dump

På tirsdag 08. mars 2016 kl. 15:43:37, skrev Adrian Klaver < adrian.kla...@aklaver.com <mailto:adrian.kla...@aklaver.com>>: On 03/08/2016 01:53 AM, Andreas Joseph Krogh wrote: > Hi all. > Is there a way to exclude pg_largeobject from pg_dump? -T pg_largeobject > doesn&

[GENERAL] Exclude pg_largeobject form pg_dump

Hi all.   Is there a way to exclude pg_largeobject from pg_dump? -T pg_largeobject doesn't work. I've tried to exclude tables using OID-datatype also but that didn't work either.   Thanks.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.c

Re: [GENERAL] Replacement for Oracle Text

his. Can this be used to index and search binary documents, e.g. pdf ?   What we do is extract plain-text from PFD/Word etc. clientside in the application, and then index that in the database. Works very well.   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@vi

Re: [GENERAL] Fatal error when not numeric value - PostgreSQL 9.2

A', E'\x1A', 'fe88ff8f-6b4d-4e3d-8020-3475a101d25e') andreak(> ) AS id(customer_id, csv_data, freshbooks_id, myob_id, ppy_id, qb_id, xero_id, _iid);  customer_id │ csv_data │ freshbooks_id │   myob_id    │ ppy_id │ qb_id │ xero_id │ _iid      ─┼──┼───┼──┼┼───┼─┼── 3915105 │ \x1A │ \x1A  │ c59894cb-0ffe-4ad6-823d-73c1392142b6 │ \x1A   │ \x1A  │ \x1A    │ 44 3915135 │ \x1A │ \x1A  │ fe88ff8f-6b4d-4e3d-8020-3475a101d25e │ \x1A   │ \x1A  │ \x1A    │ fe88ff8f-6b4d-4e3d-8020-3475a101d25e (2 rows)       Note that you have a comma after the last paren:   'fe88ff8f-6b4d-4e3d-8020-3475a101d25e'),   I had to remove that to not get this error-message:   [42601] ERROR: syntax error at or near ")"   Position: 428   -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>  

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

På fredag 15. januar 2016 kl. 16:04:00, skrev Shulgin, Oleksandr < oleksandr.shul...@zalando.de <mailto:oleksandr.shul...@zalando.de>>: On Fri, Jan 15, 2016 at 3:41 PM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På fredag 15. januar 2016 kl. 14:33:24, skrev

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

På fredag 15. januar 2016 kl. 14:33:24, skrev Shulgin, Oleksandr < oleksandr.shul...@zalando.de <mailto:oleksandr.shul...@zalando.de>>: On Fri, Jan 15, 2016 at 1:02 PM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På torsdag 14. januar 2016 kl. 00:34:51, skrev Jim N

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

På torsdag 14. januar 2016 kl. 00:34:51, skrev Jim Nasby < jim.na...@bluetreble.com <mailto:jim.na...@bluetreble.com>>: On 1/13/16 2:39 PM, Andreas Joseph Krogh wrote: > Where can I find more info about how to use and configure pg_logical to > replicate a 9.4 DB to 9.5? http

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

På onsdag 13. januar 2016 kl. 19:18:20, skrev Jim Nasby < jim.na...@bluetreble.com <mailto:jim.na...@bluetreble.com>>: On 1/13/16 2:03 AM, Andreas Joseph Krogh wrote: > Seems like pglogical migth be better? > http://2ndquadrant.com/en/resources/pglogical/ > It's av

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

På onsdag 13. januar 2016 kl. 04:17:03, skrev Vick Khera mailto:vi...@khera.org>>:   On Tue, Jan 12, 2016 at 4:20 PM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: I'm moving a > 500GB DB to another server which is initdb'ed with a different locale (nb_NO.UTF-8

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

På onsdag 13. januar 2016 kl. 03:58:27, skrev John McKown < john.archie.mck...@gmail.com <mailto:john.archie.mck...@gmail.com>>: On Tue, Jan 12, 2016 at 4:09 PM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På tirsdag 12. januar 2016 kl. 22:56:56, skrev J

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

På onsdag 13. januar 2016 kl. 00:03:18, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > What about ORDER BY on columns without an index, would they sort correctly? Sorting is sorting, it'll just use whatever collation is specified or implied. reg

  1   2   >