Re: [HACKERS] Block level parallel vacuum WIP

On Tue, Aug 23, 2016 at 6:11 PM, Michael Paquier wrote: > On Tue, Aug 23, 2016 at 8:02 PM, Masahiko Sawada > wrote: >> As for PoC, I implemented parallel vacuum so that each worker >> processes both 1 and 2 phases for particular block range. >>

Re: [HACKERS] Proposal for CSN based snapshots

On Mon, Aug 22, 2016 at 11:11 PM, Robert Haas wrote: > On Mon, Aug 22, 2016 at 1:32 PM, Heikki Linnakangas wrote: >>> But what about the best case? If we create a scenario where there are >>> no open read-write transactions at all and (somehow) lots and

Re: [HACKERS] Re: [BUGS] Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)

On 8/22/16 7:36 PM, Peter Geoghegan wrote: For some reason, both cases involved strings with code points from the Arabic alphabet, even though each case was from a totally unrelated customer database. Do those code points read right to left? Maybe that had an effect? -- Jim Nasby, Data

Re: [HACKERS] pg_receivexlog does not report flush position with --synchronous

On Tue, Aug 23, 2016 at 9:48 PM, Gabriele Bartolini wrote: > Hi Simon and Michael, > > 2016-08-23 10:39 GMT+02:00 Simon Riggs : >> >> Agreed, but I'd move all the comments above the block. > > > That's fine with me. +1. -- Michael --

Re: [HACKERS] Block level parallel vacuum WIP

On 23.08.2016 15:41, Michael Paquier wrote: On Tue, Aug 23, 2016 at 8:02 PM, Masahiko Sawada wrote: As for PoC, I implemented parallel vacuum so that each worker processes both 1 and 2 phases for particular block range. Suppose we vacuum 1000 blocks table with 4

Re: [HACKERS] pg_receivexlog does not report flush position with --synchronous

Hi Simon and Michael, 2016-08-23 10:39 GMT+02:00 Simon Riggs : > > Agreed, but I'd move all the comments above the block. > That's fine with me. Thanks, Gabriele -- Gabriele Bartolini - 2ndQuadrant Italia - Director PostgreSQL Training, Services and Support

Re: [HACKERS] Block level parallel vacuum WIP

On Tue, Aug 23, 2016 at 8:02 PM, Masahiko Sawada wrote: > As for PoC, I implemented parallel vacuum so that each worker > processes both 1 and 2 phases for particular block range. > Suppose we vacuum 1000 blocks table with 4 workers, each worker > processes 250 consecutive

Re: [HACKERS] Block level parallel vacuum WIP

On Tue, Aug 23, 2016 at 3:32 PM, Tom Lane wrote: > Claudio Freire writes: > > Not only that, but from your description (I haven't read the patch, > > sorry), you'd be scanning the whole index multiple times (one per > > worker). > > What about

Re: [HACKERS] Logical decoding of sequence advances, part II

On 23 Aug 2016 20:10, "Kevin Grittner" wrote: > > On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer wrote: > > On 23 Aug 2016 05:43, "Kevin Grittner" wrote: > >> On Mon, Aug 22, 2016 at 3:29 PM, Robert Haas wrote:

Re: [HACKERS] Block level parallel vacuum WIP

Claudio Freire writes: > Not only that, but from your description (I haven't read the patch, > sorry), you'd be scanning the whole index multiple times (one per > worker). What about pointing each worker at a separate index? Obviously the degree of concurrency during

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

Tomas Vondra writes: > On 08/22/2016 07:42 PM, Alvaro Herrera wrote: >> Also, if we patch it this way and somebody has a slow query because of a >> lot of duplicate values, it's easy to solve the problem by >> de-duplicating. But with the current code, people that

Re: [HACKERS] Logical decoding of sequence advances, part II

On Tue, Aug 23, 2016 at 7:10 AM, Kevin Grittner wrote: > On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer wrote: >> Could you provide an example of a case where xacts replayed in >> commit order will produce incorrect results? > >

Re: [HACKERS] Block level parallel vacuum WIP

I repeat your test on ProLiant DL580 Gen9 with Xeon E7-8890 v3. pgbench -s 100 and command vacuum pgbench_acounts after 10_000 transactions: with: alter system set vacuum_cost_delay to DEFAULT; parallel_vacuum_workers | time 1 | 138.703,263 ms 2 |

Re: [HACKERS] Block level parallel vacuum WIP

On Tue, Aug 23, 2016 at 8:02 AM, Masahiko Sawada wrote: > > 2. Vacuum table and index (after 1 transaction executed) > 1 worker : 12 sec > 2 workers : 49 sec > 3 workers : 54 sec > 4 workers : 53 sec > > As a result of my test, since multiple process could

[HACKERS] comment typo lmgr.c

comment typo in src/backend/storage/lmgr.c attached Erik Rijkers--- src/backend/storage/lmgr/lmgr.c.orig 2016-08-23 14:04:33.0 +0200 +++ src/backend/storage/lmgr/lmgr.c 2016-08-23 14:05:41.0 +0200 @@ -33,7 +33,7 @@ * constraint violations. It's theoretically possible that a

Re: [HACKERS] Logical decoding of sequence advances, part II

On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer wrote: > On 23 Aug 2016 05:43, "Kevin Grittner" wrote: >> On Mon, Aug 22, 2016 at 3:29 PM, Robert Haas wrote: >> >>> it seems to me that >>> this is just one facet of a much more

Re: [HACKERS] LSN as a recovery target

On Tue, Aug 23, 2016 at 6:10 PM, Simon Riggs wrote: > On 23 August 2016 at 09:39, Petr Jelinek wrote: > >> Looks very reasonable to me (both patches). Thanks for doing that. >> >> I am inclined to mark this as ready for committer. > > Looking at it

[HACKERS] Block level parallel vacuum WIP

Hi all, I'd like to propose block level parallel VACUUM. This feature makes VACUUM possible to use multiple CPU cores. Vacuum Processing Logic === PostgreSQL VACUUM processing logic consists of 2 phases, 1. Collecting dead tuple locations on heap. 2. Reclaiming dead tuples from

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 23/08/16 11:27, Craig Ringer wrote: On 23 Aug 2016 16:02, "Petr Jelinek" > wrote: On 23/08/16 02:55, Craig Ringer wrote: On 23 August 2016 at 01:03, Robert Haas

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 23 Aug 2016 16:02, "Petr Jelinek" wrote: > > On 23/08/16 02:55, Craig Ringer wrote: >> >> On 23 August 2016 at 01:03, Robert Haas > > wrote: >> >> >> >> I think you should use underscores to separate all of the

Re: [HACKERS] LSN as a recovery target

On 23 August 2016 at 09:39, Petr Jelinek wrote: > Looks very reasonable to me (both patches). Thanks for doing that. > > I am inclined to mark this as ready for committer. Looking at it now. The messages for recovery_target_lsn don't mention after or before, as do other

Re: [HACKERS] LSN as a recovery target

On 08/23/2016 10:39 AM, Petr Jelinek wrote: > On 23/08/16 09:33, Michael Paquier wrote: >> On Tue, Aug 23, 2016 at 12:49 AM, Robert Haas >> wrote: >>> On Mon, Aug 22, 2016 at 8:28 AM, Michael Paquier >>> wrote: On Mon, Aug 22, 2016 at 7:12

Re: [HACKERS] LSN as a recovery target

On 23/08/16 09:33, Michael Paquier wrote: On Tue, Aug 23, 2016 at 12:49 AM, Robert Haas wrote: On Mon, Aug 22, 2016 at 8:28 AM, Michael Paquier wrote: On Mon, Aug 22, 2016 at 7:12 PM, Adrien Nayrat wrote: As Julien

Re: [HACKERS] pg_receivexlog does not report flush position with --synchronous

On 23 August 2016 at 08:56, Michael Paquier wrote: > On Tue, Aug 23, 2016 at 7:34 AM, Gabriele Bartolini > wrote: I'd suggest rewording it a bit instead, please see attached. > And of course this needs a backpatch. Agreed, but I'd

Re: [HACKERS] pg_dump with tables created in schemas created by extensions

On Sat, Aug 13, 2016 at 6:58 AM, Martín Marqués wrote: > I believe the fix will be simple after the back and forth mails with > Michael, Stephen and Tom. I will work on that later, but preferred to > have the tests the show the problem which will also make testing the fix

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 23/08/16 02:55, Craig Ringer wrote: On 23 August 2016 at 01:03, Robert Haas > wrote: I think you should use underscores to separate all of the words instead of only some of them. ifassigned => if_assigned ifrecent=> if_recent

Re: [HACKERS] pg_receivexlog does not report flush position with --synchronous

On Tue, Aug 23, 2016 at 7:34 AM, Gabriele Bartolini wrote: > Looking up the code in more details I see that, unless replication slot > are enabled, pg_receivexlog does not report the flush position (this is a > precaution that's been taken when '--synchronous'

Re: [HACKERS] LSN as a recovery target

On Tue, Aug 23, 2016 at 12:49 AM, Robert Haas wrote: > On Mon, Aug 22, 2016 at 8:28 AM, Michael Paquier > wrote: >> On Mon, Aug 22, 2016 at 7:12 PM, Adrien Nayrat >> wrote: >>> As Julien said, there is nothing to

Re: [HACKERS] Tracking wait event for latches

On Mon, Aug 22, 2016 at 6:46 PM, Alexander Korotkov wrote: > On Mon, Aug 22, 2016 at 12:09 PM, Alexander Korotkov > wrote: >> >> I took a look at your patch. Couple of notes from me. >> >>> const char * >>> GetEventIdentifier(uint16 eventId)

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 23 August 2016 at 08:27, Craig Ringer wrote: > On 10 August 2016 at 14:44, Michael Paquier > wrote: > >> > I am looking a bit more seriously at this patch and assigned myself as >> a reviewer. >> > > Much appreciated. > > >> > macos

Re: [HACKERS] Write Ahead Logging for Hash Indexes

Hi All, Following are the steps that i have followed to verify the WAL Logging of hash index, 1. I used Mithun's patch to improve coverage of hash index code [1] to verify the WAL Logging of hash index. Firstly i have confirmed if all the XLOG records associated with hash index are being covered

Re: [HACKERS] "Some tests to cover hash_index"

Hi, I missed to attach the patch in my previous mail. Here i attach the patch. With Regards, Ashutosh Sharma EnterpriseDB:http://www.enterprisedb.com On Tue, Aug 23, 2016 at 11:47 AM, Ashutosh Sharma wrote: > Hi All, > > I have reverified the code coverage for hash

Re: [HACKERS] "Some tests to cover hash_index"

Hi All, I have reverified the code coverage for hash index code using the test file (commit-hash_coverage_test) attached with this mailing list and have found that some of the code in _hash_squeezebucket() function flow is not being covered. For this i have added a small testcase on top of

Re: [HACKERS] Patch: initdb: "'" for QUOTE_PATH (non-windows)

Thanks for committing it Tom! Thank you all for your help. I really like the Postgres project! If there's anything that especially needs worked on let me know, I'd love to help. Best, Ryan

<    1   2