Re: proposal: alternative psql commands quit and exit

Why not just use ctrl+D shortcut? This EOF signal works both in bash, mysql, psql, any CLI tool which I remember

Is it possible and worthy to optimize scanRTEForColumn()?

Hello, When I run a select query, e.g. select id from t, all columns in table "t" are checked to see if a column named "id" exists or not, and a Var is created for "id" if the column does exist. Function scanRTEForColumn() does this job. But I see in scanRTEForColumn(), the loop does not stop

Re: Speeding up pg_upgrade

On Thu, Dec 7, 2017 at 10:37:30AM -0500, Stephen Frost wrote: > Alexander, > > * Alexander Kukushkin (cyberd...@gmail.com) wrote: > > Couple of months ago we at Zalando upgraded a few databases of different > > sizes to 9.6. > > Thanks for sharing your experience! > > > During preparations to t

plpgsql: remove useless distinctions between record and row cases

I've been fooling around with rewriting plpgsql's composite-variable handling, along the way to getting it to handle domains over composite. I noticed that there's some really unnecessary complication in places where it insists on separating "row" variables from "record" variables. More usually, we

Re: proposal: alternative psql commands quit and exit

Everaldo Canuto wrote: > Some of us unfortunately have to work with multiple databases like Oracle or > MySQL. > Their respective clients mysql and sqlplus uses "quit" or "exit" to exit sql > client. > > Oracle's sqlplus uses "quit" or "exit" and MySQL client can be exited using > "quit" and "ex

Re: Partition-wise aggregation/grouping

On Fri, Dec 8, 2017 at 3:08 AM, legrand legrand wrote: > Hello, > > I'm testing Partition wise and found a strange result in V8 patch > see init_star_schema_agg.sql > > > Explain gives > -> Seq Scan on facts_p2 (...) (

RE: User defined data types in Logical Replication

Hi Sawada-san, > On Thu, Dec 7, 2017 at 11:07 AM, Masahiko Sawada > wrote: > > On Thu, Dec 7, 2017 at 12:23 AM, Dang Minh Huong > wrote: > >> Hi Sawada-san, > >> > >> Sorry for my late response. > >> > >> On 2017/12/05 0:11, Masahiko Sawada wrote: > >> > >> There is one more case that user-defin

Re: explain analyze output with parallel workers - question about meaning of information for explain.depesz.com

On Fri, Dec 8, 2017 at 12:06 AM, Robert Haas wrote: > On Wed, Dec 6, 2017 at 1:05 AM, Amit Kapila wrote: >> Right and seeing that I have prepared the patch (posted above [1]) >> which fixes it such that it will resemble the non-parallel case. >> Ideally, it would have obviated the need for my pre

Re: User defined data types in Logical Replication

On Thu, Dec 7, 2017 at 11:07 AM, Masahiko Sawada wrote: > On Thu, Dec 7, 2017 at 12:23 AM, Dang Minh Huong wrote: >> Hi Sawada-san, >> >> Sorry for my late response. >> >> On 2017/12/05 0:11, Masahiko Sawada wrote: >> >> There is one more case that user-defined data type is not supported in >> Lo

Re: How to use set/reset role in contrib_regression test?

On Fri, Dec 8, 2017 at 8:12 AM, David G. Johnston wrote: > Probably -bugs (or -general if you are unsure about the buggy-ness) would > have been a more appropriate list since this is all direct SQL that looks to > be broken. No use moving it now, though. On HEAD, REL_10_STABLE or REL9_6_STABLE,

Re: Usage of epoch in txid_current

On Wed, Dec 6, 2017 at 11:26 PM, Andres Freund wrote: > >> Either way, it is not clear to me how we will keep it >> updated after recovery. Right now, the mechanism is quite simple, at >> the beginning of a recovery we take the value of nextXid from >> checkpoint record and then if any xlog recor

Re: Logical replication without a Primary Key

On 07/12/17 21:19, Robert Haas wrote: > On Thu, Dec 7, 2017 at 2:53 PM, Chapman Flack wrote: >> On 12/07/2017 02:38 PM, Joshua D. Drake wrote: >>> AB C >>> foo,bar,baz >>> foo,bar,baz >>> >>> And then I say: >>> >>> UPDATE test set A = 1 where C = baz >>> >>> I have updated two rows because

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Fri, Dec 8, 2017 at 2:23 PM, Thomas Munro wrote: > On Fri, Dec 8, 2017 at 1:57 PM, Peter Geoghegan wrote: >> 1. Thomas' barrier abstraction was added by commit 1145acc7. I think >> that you should use a static barrier in tuplesort.c now, and rip out >> the ConditionVariable fields in the Share

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Fri, Dec 8, 2017 at 1:57 PM, Peter Geoghegan wrote: > 1. Thomas' barrier abstraction was added by commit 1145acc7. I think > that you should use a static barrier in tuplesort.c now, and rip out > the ConditionVariable fields in the Sharedsort struct. It's only a > slightly higher level of abstr

Re: Postgres with pthread

On 8 December 2017 at 03:58, Andres Freund wrote: > On 2017-12-07 11:26:07 +0800, Craig Ringer wrote: > > PostgreSQL's architecture conflates "connection", "session" and > "executor" > > into one somewhat muddled mess. > > How is the executor entangled in the other two? > > Executor in the postgr

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Thu, Dec 7, 2017 at 12:25 AM, Rushabh Lathia wrote: > 0001-Add-parallel-B-tree-index-build-sorting_v14.patch Cool. I'm glad that we now have a patch that applies cleanly against master, while adding very little to buffile.c. It feels like we're getting very close here. >> * You didn't point o

Re: Add %r substitution for psql prompts to show recovery status

> On Wed, Dec 6, 2017 at 9:19 PM, Ian Barwick > wrote: >> Note this substitution sends a "pg_is_in_recovery()" query to the server >> each time it's encountered; unless there's something I'm overlooking I >> think that's the only reliable way to determine current recovery status. > > That seems

Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

Hi David. On 2017/12/07 19:48, David Rowley wrote: > On 30 November 2017 at 11:15, Robert Haas wrote: >> Committed 0004 after reviewing the code and testing that it seems to >> work as advertised. >> >> 0005 looks like it might need to be split into smaller patches. More >> broadly, the commit m

Re: [HACKERS] SERIALIZABLE with parallel query

On Thu, Nov 30, 2017 at 2:44 PM, Thomas Munro wrote: > On Thu, Nov 30, 2017 at 2:32 PM, Michael Paquier > wrote: >> Could this question be answered? The patch still applies so I am >> moving it to next CF. Rebased, 'cause it broke. -- Thomas Munro http://www.enterprisedb.com ssi-parallel-v9.

Re: [HACKERS] Parallel Hash take II

On 2017-12-08 12:07:04 +1300, Thomas Munro wrote: > I suppose if we wanted to make this type of problem go away, but still > keep files for forensic purposes, we could introduce a "restart > number", and stick it into the top level temporary directory's name. > That way you'd never be able to colli

Re: [HACKERS] Transaction control in procedures

On 12/06/2017 09:41 AM, Peter Eisentraut wrote: > On 12/5/17 13:33, Robert Haas wrote: >> On Tue, Dec 5, 2017 at 1:25 PM, Peter Eisentraut >> wrote: >>> I think ROLLBACK in a cursor loop might not make sense, because the >>> cursor query itself could have side effects, so a rollback would have t

proposal: alternative psql commands quit and exit

Some of us unfortunately have to work with multiple databases like Oracle or MySQL. Their respective clients mysql and sqlplus uses "quit" or "exit" to exit sql client. Oracle's sqlplus uses "quit" or "exit" and MySQL client can be exited using "quit" and "exit" but for compatibility with psql, it

Re: [HACKERS] Parallel Hash take II

On Fri, Dec 8, 2017 at 12:07 PM, Thomas Munro wrote: > I suppose if we wanted to make this type of problem go away, but still > keep files for forensic purposes, we could introduce a "restart > number", and stick it into the top level temporary directory's name. > That way you'd never be able to c

Re: How to use set/reset role in contrib_regression test?

On Thu, Dec 7, 2017 at 3:55 PM, Jeremy Finzel wrote: > Hello! I hope this is the right list for extension dev questions? > > SELECT CURRENT_ROLE; > current_user > -- > jfinzel > (1 row) > > SET ROLE test_pgl_ddl_deploy; > CREATE SCHEMA special; > CREATE TABLE special.foo (id serial

Re: [HACKERS] Parallel Hash take II

On Sat, Dec 2, 2017 at 4:46 PM, Thomas Munro wrote: > On Sat, Dec 2, 2017 at 3:54 PM, Thomas Munro > wrote: >> On Sat, Dec 2, 2017 at 1:55 PM, Andres Freund wrote: >>> - As we don't clean temp files after crash-restarts it isn't impossible >>> to have a bunch of crash-restarts and end up with

Re: [HACKERS] Proposal: Local indexes for partitioned table

On 8 December 2017 at 11:23, Robert Haas wrote: > On Thu, Dec 7, 2017 at 4:57 PM, David Rowley > wrote: >> That's true, but is it worth inventing/maintaining an ATTACH syntax >> for that? It's not a very common case that multiple matching indexes >> existing. If it is worth it, do we need DETACH

How to use set/reset role in contrib_regression test?

Hello! I hope this is the right list for extension dev questions? I am finding odd behavior running make installcheck for a postgres extension. The user running the suite is a superuser ("jfinzel"). Once I create any object as a test role, reset role does not work, although it does work to do s

Re: [HACKERS] Proposal: Local indexes for partitioned table

On Thu, Dec 7, 2017 at 4:57 PM, David Rowley wrote: >> Sure, that would fix the problem I'm concerned about, but creating the >> parent index first, as a shell, and then creating each child and >> attaching it to the parent *also* fixes the problem I'm concerned >> about, and without dragging any

Re: [HACKERS] Runtime Partition Pruning

On 7 December 2017 at 23:56, Beena Emerson wrote: > Currently Amit's v13 patches do not apply on the HEAD and I was > working on 487a0c1518af2f3ae2d05b7fd23d636d687f28f3 which is the last > commit where all Amit's v13 patches applies cleanly. Thanks. I was just looking over this and was wonderin

Re: [HACKERS] Proposal: Local indexes for partitioned table

On 8 December 2017 at 10:51, Robert Haas wrote: > On Thu, Dec 7, 2017 at 4:43 PM, David Rowley > wrote: >> And yeah, this does nothing for making sure we choose the correct >> index if more than one matching index exists on the leaf partition, >> but perhaps we can dump a series of >> >> ALTER IN

Re: [HACKERS] Proposal: Local indexes for partitioned table

On Thu, Dec 7, 2017 at 4:43 PM, David Rowley wrote: > And yeah, this does nothing for making sure we choose the correct > index if more than one matching index exists on the leaf partition, > but perhaps we can dump a series of > > ALTER INDEX p_a_idx REPLACE INDEX FOR p1 WITH p1_a_idx; > ALTER IN

Re: [HACKERS] Proposal: Local indexes for partitioned table

On 8 December 2017 at 10:07, Robert Haas wrote: > I do agree with you that an index which is currently enforcing a > unique constraint has to remain continuously valid -- or if it > unavoidably doesn't, for example if we allowed an unlogged unique > index on a logged table, then we'd have to do so

Re: Add %r substitution for psql prompts to show recovery status

On Wed, Dec 6, 2017 at 7:19 PM, Ian Barwick wrote: > A possible alternative would be only to check the status each time a new > database connection is made, but that wouldn't catch the case where the > server has been promoted. > ​Can we cache a false pg_is_in_recovery response and return that i

Re: Partition-wise aggregation/grouping

Hello, I'm testing Partition wise and found a strange result in V8 patch see init_star_schema_agg.sql Explain gives -> Seq Scan on facts_p2 (...) (actual time=0.012..0.012 rows=1 loops=1) for partitions that are jo

Re: Add %r substitution for psql prompts to show recovery status

On Wed, Dec 6, 2017 at 9:19 PM, Ian Barwick wrote: > Note this substitution sends a "pg_is_in_recovery()" query to the server > each time it's encountered; unless there's something I'm overlooking I > think that's the only reliable way to determine current recovery status. That seems kinda painfu

Re: [HACKERS] Proposal: Local indexes for partitioned table

On Tue, Dec 5, 2017 at 7:42 PM, David Rowley wrote: > On 6 December 2017 at 11:35, Robert Haas wrote: >> What are we giving up by explicitly attaching >> the correct index? > > The part I don't like about the ATTACH and DETACH of partitioned index > is that it seems to be trying to just follow th

Re: explain analyze output with parallel workers - question about meaning of information for explain.depesz.com

On Fri, Dec 8, 2017 at 7:36 AM, Robert Haas wrote: > On Wed, Dec 6, 2017 at 1:05 AM, Amit Kapila wrote: >> Right and seeing that I have prepared the patch (posted above [1]) >> which fixes it such that it will resemble the non-parallel case. > > Long story short, I like the patch. LGTM. There m

Re: Postgres with pthread

Hi, On 2017-12-07 20:48:06 +, Greg Stark wrote: > But then I thought about it a bit and I do wonder. I don't know how > well we test having multiple portals doing all kinds of different > query plans with their execution interleaved. Cursors test that pretty well. > And I definitely have do

Re: Postgres with pthread

On 7 December 2017 at 19:58, Andres Freund wrote: > On 2017-12-07 11:26:07 +0800, Craig Ringer wrote: >> PostgreSQL's architecture conflates "connection", "session" and "executor" >> into one somewhat muddled mess. > > How is the executor entangled in the other two? I was going to ask the same qu

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On 2017-12-07 17:41:56 -0300, Alvaro Herrera wrote: > > > Looking at 0002: I agree with the stuff being done here. I think a > > > couple of these checks could be moved one block outerwards in term of > > > scope; I don't see any reason why the check should not apply in that > > > case. I didn't

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Hello, Andres Freund wrote: > On 2017-12-06 17:23:55 -0300, Alvaro Herrera wrote: > > > I've played around quite some with the attached patch. So far, after > > > applying the second patch, neither VACUUM nor VACUUM FULL / CLUSTER make > > > the situation worse for already existing corruption. HO

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On 2017-12-07 12:08:38 +0900, Michael Paquier wrote: > > Your commit message does a poor job of acknowledging prior work on > > diagnosing the problem starting from Dan's initial test case and patch. > > (Nit: I have extracted from the test case of Dan an isolation test, > which Andres has reduced

Re: Logical replication without a Primary Key

On 2017-12-07 11:38:51 -0800, Joshua D. Drake wrote: > On 12/07/2017 10:49 AM, Robert Haas wrote: > > On Thu, Dec 7, 2017 at 9:43 AM, Petr Jelinek > > wrote: > > > No it won't, it will update only one row, it does not try to find > > > multiple matching rows. > > Good, because that's exactly what

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Hi, On 2017-12-06 17:23:55 -0300, Alvaro Herrera wrote: > > I've played around quite some with the attached patch. So far, after > > applying the second patch, neither VACUUM nor VACUUM FULL / CLUSTER make > > the situation worse for already existing corruption. HOT pruning can > > change the exac

Re: plpgsql test layout

2017-12-07 20:08 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 11/14/17 11:51, Pavel Stehule wrote: > > One option would be to create a new test setup under > src/pl/pgsql(/src) > > and move some of the test material from the main test suite there. > Some > > of

Re: Logical replication without a Primary Key

On Thu, Dec 7, 2017 at 2:53 PM, Chapman Flack wrote: > On 12/07/2017 02:38 PM, Joshua D. Drake wrote: >> AB C >> foo,bar,baz >> foo,bar,baz >> >> And then I say: >> >> UPDATE test set A = 1 where C = baz >> >> I have updated two rows because there is no primary key to identify the >> differe

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Hi, On 2017-12-06 13:21:15 -0300, Alvaro Herrera wrote: > I think you've done a stellar job of identifying what the actual problem > was. I like the new (simpler) coding of that portion of > HeapTupleSatisfiesVacuum. Thanks! > freeze-the-dead is not listed in isolation_schedule; an easy fix. Y

Re: Signals in a BGW

On 12/07/2017 02:58 PM, Andres Freund wrote: > On 2017-12-07 12:35:07 -0500, Robert Haas wrote: >> On Wed, Dec 6, 2017 at 6:59 PM, Chapman Flack wrote: The default handler is bgworker_die ; see src/backend/postmaster /bgworker.c . I don't know if elog() is safe in a signal handler,

Re: Postgres with pthread

On 2017-12-07 11:26:07 +0800, Craig Ringer wrote: > PostgreSQL's architecture conflates "connection", "session" and "executor" > into one somewhat muddled mess. How is the executor entangled in the other two? Greetings, Andres Freund

Re: Signals in a BGW

On 2017-12-07 12:35:07 -0500, Robert Haas wrote: > On Wed, Dec 6, 2017 at 6:59 PM, Chapman Flack wrote: > >> The default handler is bgworker_die ; see src/backend/postmaster > >> /bgworker.c > >> . I don't know if elog() is safe in a signal handler, but I guess in > >> the absence of non-reentrant

Re: Logical replication without a Primary Key

On 12/07/2017 02:38 PM, Joshua D. Drake wrote: > A    B   C > foo,bar,baz > foo,bar,baz > > And then I say: > > UPDATE test set A = 1 where C = baz > > I have updated two rows because there is no primary key to identify the > differences. Both of those rows should be updated and thus replicated

Re: [HACKERS] CUBE seems a bit confused about ORDER BY

On Wed, Nov 29, 2017 at 3:10 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > I'll try to provide meaningful review next week. >> > > Cool, thanks. > Andrey Borodin complained through Telegram that he can't apply my patches using "git apply". After investigation of this problem, it a

Re: [HACKERS] logical decoding of two-phase transactions

On 12/7/17 08:31, Peter Eisentraut wrote: > On 12/4/17 10:15, Nikhil Sontakke wrote: >> PFA, latest patch for this functionality. > > This probably needs documentation updates for the logical decoding chapter. You need the attached patch to be able to compile without warnings. Also, the regressi

Re: Logical replication without a Primary Key

On 12/07/2017 10:49 AM, Robert Haas wrote: On Thu, Dec 7, 2017 at 9:43 AM, Petr Jelinek wrote: No it won't, it will update only one row, it does not try to find multiple matching rows. Good, because that's exactly what it should do. I mean, if you have on the master two tuples that are identi

Re: [HACKERS] A design for amcheck heapam verification

On Tue, Nov 28, 2017 at 9:54 PM, Peter Geoghegan wrote: > On Tue, Nov 28, 2017 at 9:50 PM, Michael Paquier > wrote: >>> Would that address your concern? There would be an SQL interface, but >>> it would be trivial. >> >> That's exactly what I think you should do, and mentioned so upthread. >> A S

Re: Transform for pl/perl

On 12/1/17 13:15, Tom Lane wrote: > Robert Haas writes: >> On Fri, Dec 1, 2017 at 12:30 AM, Michael Paquier >> wrote: >>> Patch moved to CF 2018-01. Perhaps a committer will look at it at some >>> point. > >> FWIW, although I like the idea, I'm not going to work on the patch. I >> like Perl, b

Re: Speeding up pg_upgrade

Tom, David, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Well, if it's dropped, I think we need to make sure that users are aware > > of that going in and that's why I was suggesting a switch. If you've > > got a better idea for that, great, but having certain pg_upgrade >

Re: Speeding up pg_upgrade

On Thu, Dec 7, 2017 at 12:04 PM, Stephen Frost wrote: > If you've > got a better idea for that, great, but having certain pg_upgrade > migrations require running ANALYZE and some migrations not require it is > something we need to make users *very* clear about. No, I don't think a > note in the

Re: Speeding up pg_upgrade

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Yeah, there's that. But the rate of change in pg_statistic hasn't been >> *that* large. Alvaro might be right that we can design some transmission >> procedure that allows stats to be forward-migrated when compatible and >> droppe

Re: plpgsql test layout

On 11/14/17 11:51, Pavel Stehule wrote: > One option would be to create a new test setup under src/pl/pgsql(/src) > and move some of the test material from the main test suite there.  Some > of the test cases in the main test suite are more about SPI and triggers > and such, so it m

Re: Speeding up pg_upgrade

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > If we go down that route, since this makes a pretty serious difference > > in terms of what the user has to deal with post-pg_upgrade, I'd suggest > > we require an additional option for the user to pass when stats aren't > >

Re: Speeding up pg_upgrade

Stephen Frost writes: > If we go down that route, since this makes a pretty serious difference > in terms of what the user has to deal with post-pg_upgrade, I'd suggest > we require an additional option for the user to pass when stats aren't > going to be migrated, so they are aware of that. -1 .

Re: Mention ordered datums in PartitionBoundInfoData comment

On Tue, Dec 5, 2017 at 1:03 AM, Ashutosh Bapat wrote: > Sorry. Thanks for pointing it out. fixed in the attached patch. + * The datums in datums array are arranged in the increasing order defined by Suggest: in increasing order as defined There's a second place where the same change is needed.

Re: Speeding up pg_upgrade

Alvaro Herrera writes: > Tom Lane wrote: >> The reason pg_upgrade hasn't done that in the past is not wishing to >> assume that the new version does stats identically to the old version. >> Since we do in fact add stats or change stuff around from time to time, >> that's not a negligible considera

Re: Logical replication without a Primary Key

On Thu, Dec 7, 2017 at 9:43 AM, Petr Jelinek wrote: > No it won't, it will update only one row, it does not try to find > multiple matching rows. Good, because that's exactly what it should do. I mean, if you have on the master two tuples that are identical, and you update one of them, then the

Re: pgsql: Support Parallel Append plan nodes.

On Thu, Dec 7, 2017 at 6:01 AM, Amit Khandekar wrote: > I have not managed to make the regression test cases execute the above > not-covered case. I could do that with my local test that I have, but > that test has lots of data, so it is slow, and not suitable for > regression. In select_parallel.

Re: Speeding up pg_upgrade

Tom Lane wrote: > Alvaro Herrera writes: > > It seems pretty clear to me that we should somehow transfer stats from > > the old server to the new one. Shouldn't it just be a matter of > > serializing the MCV/histogram/ndistinct values, then have capabilities > > to load on the new server? > > Th

Re: explain analyze output with parallel workers - question about meaning of information for explain.depesz.com

On Wed, Dec 6, 2017 at 1:05 AM, Amit Kapila wrote: > Right and seeing that I have prepared the patch (posted above [1]) > which fixes it such that it will resemble the non-parallel case. > Ideally, it would have obviated the need for my previous patch which > got committed as 778e78ae. However, n

Re: Speeding up pg_upgrade

Robert, all, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Dec 7, 2017 at 11:42 AM, Tom Lane wrote: > > Alvaro Herrera writes: > >> It seems pretty clear to me that we should somehow transfer stats from > >> the old server to the new one. Shouldn't it just be a matter of > >> serializi

Re: Speeding up pg_upgrade

On Thu, Dec 7, 2017 at 11:42 AM, Tom Lane wrote: > Alvaro Herrera writes: >> It seems pretty clear to me that we should somehow transfer stats from >> the old server to the new one. Shouldn't it just be a matter of >> serializing the MCV/histogram/ndistinct values, then have capabilities >> to l

Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug

On Tue, Nov 7, 2017 at 7:51 AM, Jan Przemysław Wójcik wrote: > I'm afraid that creating a function that implements quite different > algorithms depending on a global parameter seems very hacky and would lead > to misunderstandings. I do understand the need of backward compatibility, > but I'd opt

Re: Postgres with pthread

On Wed, Dec 6, 2017 at 10:20 PM, Craig Ringer wrote: > Personally I think it's a pity we didn't land up here before the foundations > for parallel query went in - DSM, shm_mq, DSA, etc. I know the EDB folks at > least looked into it though, and presumably there were good reasons to go in > this di

Re: [BUGS] pg_trgm word_similarity inconsistencies or bug

Hello Alexander, This is fine with us. Yes, separate thresholds seem preferable. Best Regards Obtenez Outlook pour iOS From: Alexander Korotkov Sent: Thursday, December 7, 2017 4:38:59 PM To: Jan Przemysław Wójcik; Cristiano Coelho Cc: pgsql

Re: Signals in a BGW

On Wed, Dec 6, 2017 at 6:59 PM, Chapman Flack wrote: >> The default handler is bgworker_die ; see src/backend/postmaster >> /bgworker.c >> . I don't know if elog() is safe in a signal handler, but I guess in >> the absence of non-reentrant errcontext functions... > > That does seem bold, doesn't i

Re: Speeding up pg_upgrade

Alvaro Herrera writes: > It seems pretty clear to me that we should somehow transfer stats from > the old server to the new one. Shouldn't it just be a matter of > serializing the MCV/histogram/ndistinct values, then have capabilities > to load on the new server? The reason pg_upgrade hasn't don

Re: Speeding up pg_upgrade

On Tue, Dec 05, 2017 at 09:01:35AM -0500, Bruce Momjian wrote: > As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about > zero-downtime upgrades. ... we discussed speeding up pg_upgrade. > > There are clusters that take a long time to dump the schema from the old > cluster Mayb

Re: pgsql: When VACUUM or ANALYZE skips a concurrently dropped table, log i

On Wed, Dec 6, 2017 at 9:42 PM, Bossart, Nathan wrote: > On 12/6/17, 8:25 PM, "Robert Haas" wrote: >> Please give me a little time to see if I can speed up this test enough >> to fix this problem. If that doesn't work out, then we can rip this >> out. > > Just in case it got missed earlier, here

Re: Speeding up pg_upgrade

Alvaro, * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > Stephen Frost wrote: > > * Alexander Kukushkin (cyberd...@gmail.com) wrote: > > > > 2 ANALYZE phase is a pain. I think everybody agrees with it. > > > > > > 2.5 Usually ANALYZE stage 1 completes quite fast and performance becomes > > >

Re: Speeding up pg_upgrade

Stephen Frost wrote: > Alexander, > * Alexander Kukushkin (cyberd...@gmail.com) wrote: > > 2 ANALYZE phase is a pain. I think everybody agrees with it. > > > > 2.5 Usually ANALYZE stage 1 completes quite fast and performance becomes > > reasonable, except one case: some of the columns might have

Re: Speeding up pg_upgrade

Alexander, * Alexander Kukushkin (cyberd...@gmail.com) wrote: > Couple of months ago we at Zalando upgraded a few databases of different > sizes to 9.6. Thanks for sharing your experience! > During preparations to the I've found 2.5 pain-points: > > 1. We are using schema-based api deployment.

Re: Postgres with pthread

On 7 December 2017 at 19:55, Konstantin Knizhnik wrote: > > Pros: > 1. Simplified memory model: no need in DSM, shm_mq, DSA, etc > shm_mq would remain useful, and the others could only be dropped if you also dropped process-model support entirely. > 1. Breaks compatibility with existed extensi

Re: Logical replication without a Primary Key

On 07/12/17 15:32, Joshua D. Drake wrote: > On 12/07/2017 05:30 AM, Peter Eisentraut wrote: >> >>> How does that work? Is it using one of the hidden columns on a row? >> It means that for example if an update record is produced, the entire >> row is included in the record as the key. > > Thanks Pe

Re: Logical replication without a Primary Key

On Thursday, December 7, 2017, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 12/6/17 19:03, Joshua D. Drake wrote: > > > > > How does that work? Is it using one of the hidden columns on a row? > > It means that for example if an update record is produced, the entire > row is inc

Re: Logical replication without a Primary Key

On 7 December 2017 at 22:32, Joshua D. Drake wrote: > > The confusion I have is what if we have two rows that are identical and > now that I think about it we would just update both rows, yes? That would > make sense because it would produce two updated rows. > > I expect so, but honestly, maybe

Re: Logical replication without a Primary Key

On 12/07/2017 05:30 AM, Peter Eisentraut wrote: How does that work? Is it using one of the hidden columns on a row? It means that for example if an update record is produced, the entire row is included in the record as the key. Thanks Peter, Craig also responded, The confusion I have is wha

Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug

On Tue, Nov 7, 2017 at 7:24 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Tue, Nov 7, 2017 at 3:51 PM, Jan Przemysław Wójcik < > jan.przemyslaw.woj...@gmail.com> wrote: > >> my statement about the function usefulness was probably too categorical, >> though I had in mind the curre

Re: [HACKERS] logical decoding of two-phase transactions

On 12/4/17 10:15, Nikhil Sontakke wrote: > PFA, latest patch for this functionality. This probably needs documentation updates for the logical decoding chapter. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Logical replication without a Primary Key

On 12/6/17 19:03, Joshua D. Drake wrote: > -Hackers, > > In the docs it says: > > " > If the table does not have any suitable key, then it can be set to > replica identity“full”, which means the entire row becomes the key. > > " > > How does that work? Is it using one of the hidden columns on

Re: compress method for spgist - 2

On Thu, Dec 7, 2017 at 3:17 AM, Nikita Glukhov wrote: > On 06.12.2017 21:49, Alexander Korotkov wrote: > > On Wed, Dec 6, 2017 at 6:08 PM, Nikita Glukhov > wrote: > >> On 05.12.2017 23:59, Alexander Korotkov wrote: >> >> On Tue, Dec 5, 2017 at 1:14 PM, Darafei Praliaskouski >> wrote: >> >>> The

Re: Postgres with pthread

On 07.12.2017 00:58, Thomas Munro wrote: Using a ton of thread local variables may be a useful stepping stone, but if we want to be able to separate threads/processes from sessions eventually then I guess we'll want to model sessions as first class objects and pass them around explicitly or usi

Re: Postgres with pthread

Hi On 06.12.2017 20:08, Andres Freund wrote: 4. Rewrite file descriptor cache to be global (shared by all threads). That one I'm very unconvinced of, that's going to add a ton of new contention. Do you mean lock contention because of mutex I used to synchronize access to shared file descript

Re: Postgres with pthread

I want to thank everybody for feedbacks and a lot of useful notices. I am very pleased with interest of community to this topic and will continue research in this direction. Some more comments from my side: My original intention was to implement some king of built-in connection pooling for Pos

Re: [HACKERS] Runtime Partition Pruning

Hello, On Thu, Dec 7, 2017 at 12:52 PM, Beena Emerson wrote: > > 1. Only runtime pruning - David's case1 > explain analyse execute ab_q1 (2,3); >QUERY PLAN > ---

Re: [HACKERS] Runtime Partition Pruning

Hello David, On Thu, Dec 7, 2017 at 4:07 PM, David Rowley wrote: > On 7 December 2017 at 20:22, Beena Emerson wrote: >> PFA the updated patch. > > Hi Beena, > > Thanks for updating this. > > Can you list the patches which are required for this to apply to > today's master branch? > Thanks for l

Re: [HACKERS] path toward faster partition pruning

On 30 November 2017 at 11:15, Robert Haas wrote: > Committed 0004 after reviewing the code and testing that it seems to > work as advertised. > > 0005 looks like it might need to be split into smaller patches. More > broadly, the commit messages you wrote for for 0005, 0006, and 0008 > don't seem

Re: [HACKERS] Runtime Partition Pruning

On 7 December 2017 at 20:22, Beena Emerson wrote: > PFA the updated patch. Hi Beena, Thanks for updating this. Can you list the patches which are required for this to apply to today's master branch? -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 S

Re: Transform for pl/perl

On Thu, 7 Dec 2017 12:54:55 +0300 Anthony Bykov wrote: > On Fri, 1 Dec 2017 15:49:21 -0300 > Alvaro Herrera wrote: > > > A few very minor comments while quickly paging through: > > > > 1. non-ASCII tests are going to cause problems in one platform or > > another. Please don't include that one

Re: Transform for pl/perl

On Fri, 1 Dec 2017 15:49:21 -0300 Alvaro Herrera wrote: > A few very minor comments while quickly paging through: > > 1. non-ASCII tests are going to cause problems in one platform or > another. Please don't include that one. > > 2. error messages >a) please use ereport() not elog() >b

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Thu, Dec 7, 2017 at 5:23 AM, Alvaro Herrera wrote: > Looking at 0002: I agree with the stuff being done here. The level of details you are providing with a proper error code is an improvement over the first version proposed in my opinion. > I think a > couple of these checks could be moved on

Re: Speeding up pg_upgrade

Hi, > Yes, dump/reload of analyze statistics seems like a better use of time. > I have avoided it since it locks us into supporting the text > respresentation of data type, but at this point it might be worth it. > > Couple of months ago we at Zalando upgraded a few databases of different sizes t

  1   2   >