Re: [HACKERS] How can we expand PostgreSQL ecosystem?

On 06/03/16 18:29, MauMau wrote: > As I said in the previous greeting mail, I'd like to discuss how to > expand PostgreSQL ecosystem. Here, ecosystem means "interoperability" > -- the software products and cloud services which use/support > PostgreSQL. If pgsql-advocacy or somewhere else is be

Re: [HACKERS] planstats.sgml

On 16/02/16 12:46, David G. Johnston wrote: On Mon, Feb 15, 2016 at 4:23 PM, Tatsuo Ishii mailto:is...@postgresql.org>>wrote: While reading planstats.sgml, I encounted a sentence which I don't understand. These numbers are current as of the last VACUUM or ANALYZE on th

Re: [HACKERS] planstats.sgml

On 16/02/16 20:01, Tatsuo Ishii wrote: Tatsuo Ishii writes: While reading planstats.sgml, I encounted a sentence which I don't understand. These numbers are current as of the last VACUUM or ANALYZE on the table. The planner then fetches the actual current number of pages in t

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 23/08/16 15:24, Amit Kapila wrote: Thoughts? Note - To use this patch, first apply latest version of concurrent hash index patch [2]. [1] - https://commitfest.postgresql.org/10/647/ [2] - https://www.postgresql.org/message-id/caa4ek1lkq_udism-z2dq6cuvjh3db5fnfnnezzbpsrjw0ha...@mail.gmail.c

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 24/08/16 12:09, Mark Kirkwood wrote: On 23/08/16 15:24, Amit Kapila wrote: Thoughts? Note - To use this patch, first apply latest version of concurrent hash index patch [2]. [1] - https://commitfest.postgresql.org/10/647/ [2] - https://www.postgresql.org/message-id/caa4ek1lkq_udism

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 24/08/16 15:36, Amit Kapila wrote: On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood wrote: On 24/08/16 12:09, Mark Kirkwood wrote: On 23/08/16 15:24, Amit Kapila wrote: Thoughts? Note - To use this patch, first apply latest version of concurrent hash index patch [2]. [1] - https

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 24/08/16 16:33, Amit Kapila wrote: On Wed, Aug 24, 2016 at 9:53 AM, Mark Kirkwood wrote: On 24/08/16 15:36, Amit Kapila wrote: On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood wrote: Can you get the call stacks? For every stuck backend? (just double checking)... Yeah. Cool, I managed

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 24/08/16 16:52, Mark Kirkwood wrote: On 24/08/16 16:33, Amit Kapila wrote: On Wed, Aug 24, 2016 at 9:53 AM, Mark Kirkwood wrote: On 24/08/16 15:36, Amit Kapila wrote: On Wed, Aug 24, 2016 at 8:54 AM, Mark Kirkwood wrote: Can you get the call stacks? For every stuck backend? (just

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 24/08/16 17:01, Mark Kirkwood wrote: ...actually I was wrong there, only 2 of them were the same. So I've attached a new log of bt's of them all. And I can reproduce with only 1 session, figured that might be a helpful piece of the puzzle (trace attached). $ pgbench

Re: [HACKERS] Write Ahead Logging for Hash Indexes

d, it might be easier to just have me test it. Okay, I have fixed this issue as explained above. Apart from that, I have fixed another issue reported by Mark Kirkwood upthread and few other issues found during internal testing by Ashutosh Sharma. The locking issue reported by Mark and Ashutosh is tha

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 09/09/16 07:09, Jeff Janes wrote: On Wed, Sep 7, 2016 at 3:29 AM, Ashutosh Sharma > wrote: > Thanks to Ashutosh Sharma for doing the testing of the patch and > helping me in analyzing some of the above issues. Hi All, I would like to summarize

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 09/09/16 14:50, Mark Kirkwood wrote: Yeah, good suggestion about replacing (essentially) all the indexes with hash ones and testing. I did some short runs with this type of schema yesterday (actually to get a feel for if hash performance vs btree was compareable - does seem tp be) - but

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 11/09/16 17:01, Amit Kapila wrote: On Sun, Sep 11, 2016 at 4:10 AM, Mark Kirkwood wrote: performed several 10 hour runs on size 100 database using 32 and 64 clients. For the last run I rebuilt with assertions enabled. No hangs or assertion failures. Thanks for verification. Do you

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 11/09/16 19:16, Mark Kirkwood wrote: On 11/09/16 17:01, Amit Kapila wrote: ...Do you think we can do some read-only workload benchmarking using this server? If yes, then probably you can use concurrent hash index patch [1] and cache the metapage patch [2] (I think Mithun needs to rebase

Re: [HACKERS] Hash Indexes

On 13/09/16 01:20, Jesper Pedersen wrote: On 09/01/2016 11:55 PM, Amit Kapila wrote: I have fixed all other issues you have raised. Updated patch is attached with this mail. The following script hangs on idx_val creation - just with v5, WAL patch not applied. Are you sure it is actually ha

Re: [HACKERS] less expensive pg_buffercache on big shmem

On 02/09/16 15:19, Andres Freund wrote: On 2016-09-02 08:31:42 +0530, Robert Haas wrote: I wonder whether we ought to just switch from the consistent method to the semiconsistent method and call it good. +1. I think, before long, we're going to have to switch away from having locks & partition

Re: [HACKERS] Hash Indexes

On 16/09/16 18:35, Amit Kapila wrote: On Thu, Sep 15, 2016 at 7:53 PM, Andres Freund wrote: Hi, On 2016-05-10 17:39:22 +0530, Amit Kapila wrote: For making hash indexes usable in production systems, we need to improve its concurrency and make them crash-safe by WAL logging them. One earlier

Re: [HACKERS] Hash Indexes

On 17/09/16 06:38, Andres Freund wrote: On 2016-09-16 09:12:22 -0700, Jeff Janes wrote: On Thu, Sep 15, 2016 at 7:23 AM, Andres Freund wrote: One earlier question about this is whether that is actually a worthwhile goal. Are the speed and space benefits big enough in the general case? Could

Re: [HACKERS] Hash Indexes

On 25/09/16 18:18, Amit Kapila wrote: On Sat, Sep 24, 2016 at 10:49 PM, Greg Stark wrote: On Thu, Sep 22, 2016 at 3:23 AM, Tom Lane wrote: But to kick the hash AM as such to the curb is to say "sorry, there will never be O(1) index lookups in Postgres". Well there's plenty of halfway solut

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

On 26/09/17 20:44, Mark Kirkwood wrote: $ pg_basebackup -D . WARNING:  could not read symbolic link "pg_tblspc/space1": Invalid argument pg_basebackup: directory "/data0/pgdata/11/pg_tblspc/space1" exists but is not empty pg_basebackup: removing contents of data

Re: [HACKERS] WIP: About CMake v2

On 11/11/16 08:15, Yury Zhuravlev wrote: Craig Ringer wrote: So personally I think it'd be fine if a cmake build defaulted to finding and using what it could, but offered a --minimal mode or whatever that gets us just core postgres + whatever we enable explicitly. But our current behaviour is O

Re: [HACKERS] WIP: About CMake v2

I had a bit a play around to see if I could get this building properly again with v10 (i.e master). I've attached a minimal *incremental* patch that needs to be applied after v1. This gets everything under the src tree building (added the new file_utils.c and reordered some link libs and remove

Re: [HACKERS] WIP: About CMake v2

Yeah, there seems to be a lot of these. Looking through them almost all concern the addition of piece of code to wrap putenv. e.g: --- a/src/bin/psql/command.c +++ b/src/bin/psql/command.c @@ -1350,7 +1350,7 @@ exec_command(const char *cmd, char *newval;

Re: [HACKERS] WIP: About CMake v2

I see there are some patches for the putenv issue with Visual studio 2013 in progress on this list - it is probably best to work with the author to see if 2015 has any new issues and keep all changes for that *out* of the cmake patches. regards Mark On 16/11/16 21:22, Yury Zhuravlev wrote

[HACKERS] Logical replication initial feedback

Hi, Thought I'd take a look at how this works (checking out current master). You guys have manged to get this to the point where it is *ridiculously* easy to set up a basic replication scenario - awesome i must say: - change a few parameters on the master (max_wal_senders,max_replication_slo

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 15/03/17 06:29, Robert Haas wrote: Great! I've committed the latest version of the patch, with some cosmetic changes. It would be astonishing if there weren't a bug or two left, but I think overall this is very solid work, and I think it's time to put this out there and see how things go.

Re: [HACKERS] Wait free LW_SHARED acquisition

On 01/07/14 23:25, Heikki Linnakangas wrote: On 07/01/2014 01:08 PM, Andres Freund wrote: Hi, Over at -performance Mark Kirkwood tested a recent version of this (http://archives.postgresql.org/message-id/53B283F3.7020005%40catalyst.net.nz) . I thought it's interesting to add the numbe

Re: [HACKERS] postgresql.auto.conf and reload

On 09/07/14 05:13, Josh Berkus wrote: On 07/06/2014 01:27 AM, Christoph Berg wrote: Another could be that during initdb all the uncommented settings be written to postgresql.auto.conf file rather than to postgresql.conf. I think we can do this by changing code in initdb.c->setup_config(). This

Re: [HACKERS] parametric block size?

On 26/07/14 21:05, Andres Freund wrote: More advanced features, but with much more impact on the code, would be to be able to change the size at database/table level. That'd be pretty horrible because the size of pages in shared_buffers wouldn't be uniform anymore. Possibly stopping at th

Re: [HACKERS] PostrgeSQL vs oracle doing 1 million sqrts am I doing it wrong?

On 05/08/14 08:48, testman1316 wrote: We am trying to get an idea of the raw performance of Oracle vs PostgreSQL. We have extensive oracle experience but are new to PostgreSQL. We are going to run lots of queries with our data, etc. But first we wanted to see just how they perform on basic kernel

Re: [HACKERS] PostrgeSQL vs oracle doing 1 million sqrts am I doing it wrong?

On 05/08/14 17:56, Mark Kirkwood wrote: Adding in the 'if' in the float8 case increases run time to 4s. So looks like plpgsql might have a slightly higher cost for handling added conditionals. Be interesting to dig a bit more and see what is taking the time. Thinking about this

Re: [HACKERS] Logical replication existing data copy

On 24/03/17 02:00, Peter Eisentraut wrote: On 3/21/17 21:38, Peter Eisentraut wrote: This patch is looking pretty good to me, modulo the failing pg_dump tests. Attached is a fixup patch. I have mainly updated some comments and variable naming for (my) clarity. No functional changes. Committe

Re: [HACKERS] Logical replication existing data copy

On 24/03/17 12:32, Petr Jelinek wrote: On 24/03/17 00:14, Mark Kirkwood wrote: On 24/03/17 02:00, Peter Eisentraut wrote: On 3/21/17 21:38, Peter Eisentraut wrote: This patch is looking pretty good to me, modulo the failing pg_dump tests. Attached is a fixup patch. I have mainly updated

Re: [HACKERS] Logical replication existing data copy

On 25/03/17 07:52, Peter Eisentraut wrote: On 3/24/17 10:09, Petr Jelinek wrote: On 24/03/17 15:05, Peter Eisentraut wrote: On 3/23/17 19:32, Petr Jelinek wrote: Yes, I also forgot to check if the table actually exists on subscriber when fetching them in CREATE SUBSCRIPTION (we have check dur

[HACKERS] New partitioning - some feedback

I've been trying out the new partitioning in version 10. Firstly, I must say this is excellent - so much nicer than the old inheritance based method! My only niggle is the display of partitioned tables via \d etc. e.g: part=# \d List of relations Schema | Name |

Re: [HACKERS] New partitioning - some feedback

On 07/07/17 13:29, Amit Langote wrote: Someone complained about this awhile back [1]. And then it came up again [2], where Noah appeared to take a stance that partitions should be visible in views / output of commands that list "tables". Although I too tend to prefer not filling up the \d out

Re: [HACKERS] New partitioning - some feedback

On 07/07/17 19:54, Michael Banck wrote: On Fri, Jul 07, 2017 at 07:40:55PM +1200, Mark Kirkwood wrote: On 07/07/17 13:29, Amit Langote wrote: Someone complained about this awhile back [1]. And then it came up again [2], where Noah appeared to take a stance that partitions should be visible

Re: [HACKERS] New partitioning - some feedback

On 16/07/17 05:24, David Fetter wrote: On Fri, Jul 14, 2017 at 09:49:25PM -0500, Robert Haas wrote: On Mon, Jul 10, 2017 at 5:46 PM, David Fetter wrote: With utmost respect, it's less messy than adding '!' to the already way too random and mysterious syntax of psql's \ commands. What should

Re: [HACKERS] autovacuum can't keep up, bloat just continues to rise

On 21/07/17 15:58, Joshua D. Drake wrote: On 07/19/2017 07:57 PM, Tom Lane wrote: Peter Geoghegan writes: My argument for the importance of index bloat to the more general bloat problem is simple: any bloat that accumulates, that cannot be cleaned up, will probably accumulate until it impacts

Re: [HACKERS] logical replication - still unstable after all these months

On 26/05/17 20:09, Erik Rijkers wrote: On 2017-05-26 09:40, Simon Riggs wrote: If we can find out what the bug is with a repeatable test case we can fix it. Could you provide more details? Thanks I will, just need some time to clean things up a bit. But what I would like is for someone

Re: [HACKERS] logical replication - still unstable after all these months

On 26/05/17 20:09, Erik Rijkers wrote: The idea is simple enough: startup instance1 startup instance2 (on same machine) primary: init pgbench tables primary: add primary key to pgbench_history copy empty tables to replica by dump/restore primary: start publication replica: start subscription p

Re: [HACKERS] logical replication - still unstable after all these months

Interesting - might be good to see your test script too (so we can better understand how you are deciding if the runs are successful or not). Also, any idea which rows are different? If you want something out of the box that will do that for you see DBIx::Compare. regards Mark On 28/05/17

Re: [HACKERS] logical replication - still unstable after all these months

Sorry - I see you have done this already. On 28/05/17 11:15, Mark Kirkwood wrote: Interesting - might be good to see your test script too (so we can better understand how you are deciding if the runs are successful or not). -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] logical replication - still unstable after all these months

On 27/05/17 20:30, Erik Rijkers wrote: Here is what I have: instances.sh: starts up 2 assert enabled sessions instances_fast.sh: alternative to instances.sh starts up 2 assert disabled 'fast' sessions testset.sh loop to call pgbench_derail2.sh with varying params pgbench_derail2.sh

Re: [HACKERS] logical replication - still unstable after all these months

On 28/05/17 19:01, Mark Kirkwood wrote: So running in cloud land now...so for no errors - will update. The framework ran 600 tests last night, and I see 3 'NOK' results, i.e 3 failed test runs (all scale 25 and 8 pgbench clients). Given the way the test decides on failure (get

Re: [HACKERS] logical replication - still unstable after all these months

On 29/05/17 16:26, Erik Rijkers wrote: On 2017-05-29 00:17, Mark Kirkwood wrote: On 28/05/17 19:01, Mark Kirkwood wrote: So running in cloud land now...so for no errors - will update. The framework ran 600 tests last night, and I see 3 'NOK' results, i.e 3 failed test runs (al

Re: [HACKERS] logical replication - still unstable after all these months

On 29/05/17 13:33, Jeff Janes wrote: On Sun, May 28, 2017 at 3:17 PM, Mark Kirkwood mailto:mark.kirkw...@catalyst.net.nz>> wrote: On 28/05/17 19:01, Mark Kirkwood wrote: So running in cloud land now...so for no errors - will update. The framework ran 600 test

Re: [HACKERS] logical replication - still unstable after all these months

On 29/05/17 23:14, Petr Jelinek wrote: On 29/05/17 03:33, Jeff Janes wrote: What would you want to look at? Would saving the WAL from the master be helpful? Useful info is, logs from provider (mainly the logical decoding logs that mention LSNs), logs from subscriber (the lines about when sy

Re: [HACKERS] logical replication - still unstable after all these months

On 31/05/17 21:16, Petr Jelinek wrote: On 29/05/17 23:06, Mark Kirkwood wrote: On 29/05/17 23:14, Petr Jelinek wrote: On 29/05/17 03:33, Jeff Janes wrote: What would you want to look at? Would saving the WAL from the master be helpful? Useful info is, logs from provider (mainly the

Re: [HACKERS] logical replication - still unstable after all these months

On 02/06/17 17:11, Erik Rijkers wrote: On 2017-06-02 00:46, Mark Kirkwood wrote: On 31/05/17 21:16, Petr Jelinek wrote: I'm seeing a new failure with the patch applied - this time the history table has missing rows. Petr, I'll put back your access :-) Is this error during 1-m

Re: [HACKERS] logical replication - still unstable after all these months

On 03/06/17 11:10, Petr Jelinek wrote: On 02/06/17 22:29, Petr Jelinek wrote: On 02/06/17 08:55, Mark Kirkwood wrote: On 02/06/17 17:11, Erik Rijkers wrote: On 2017-06-02 00:46, Mark Kirkwood wrote: On 31/05/17 21:16, Petr Jelinek wrote: I'm seeing a new failure with the patch ap

Re: [HACKERS] logical replication - still unstable after all these months

On 05/06/17 00:04, Erik Rijkers wrote: On 2017-05-31 16:20, Erik Rijkers wrote: On 2017-05-31 11:16, Petr Jelinek wrote: [...] Thanks to Mark's offer I was able to study the issue as it happened and found the cause of this. [0001-Improve-handover-logic-between-sync-and-apply-worker.patch] T

Re: [HACKERS] logical replication - still unstable after all these months

On 05/06/17 13:08, Mark Kirkwood wrote: On 05/06/17 00:04, Erik Rijkers wrote: On 2017-05-31 16:20, Erik Rijkers wrote: On 2017-05-31 11:16, Petr Jelinek wrote: [...] Thanks to Mark's offer I was able to study the issue as it happened and found the cause of this. [0001-Improve-han

Re: [HACKERS] Make ANALYZE more selective about what is a "most common value"?

On 05/06/17 09:30, Tom Lane wrote: I've been thinking about the behavior discussed in https://www.postgresql.org/message-id/flat/20170522132017.29944.48391%40wrigleys.postgresql.org and it seems to me that there are a couple of things we ought to do about it. First, I think we need a larger har

Re: [HACKERS] Make ANALYZE more selective about what is a "most common value"?

On 06/06/17 10:12, Gavin Flower wrote: On 06/06/17 09:41, Mark Kirkwood wrote: On 05/06/17 09:30, Tom Lane wrote: I've been thinking about the behavior discussed in https://www.postgresql.org/message-id/flat/20170522132017.29944.48391%40wrigleys.postgresql.org and it seems to me that

Re: [HACKERS] logical replication: \dRp+ and "for all tables"

On 15/06/17 11:10, Tom Lane wrote: Jeff Janes writes: On Sat, Jun 10, 2017 at 7:42 AM, Tom Lane wrote: In the second place, this really fails to respond to what I'd call the main usability problem with \dRp+, which is that the all-tables property is likely to lead to an unreadably bulky list

Re: [HACKERS] MAIN, Uncompressed?

On 26/08/17 12:18, Simon Riggs wrote: On 25 August 2017 at 20:53, Tom Lane wrote: Greg Stark writes: I think this is a particularly old piece of code and we're lucky the default heuristics have served well for all this time because I doubt many people fiddle with these storage attributes. Th

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

On 29/04/15 09:35, Bruce Momjian wrote: On Fri, Apr 24, 2015 at 01:05:03PM -0400, Bruce Momjian wrote: This way, both pg_dump and pg_upgrade will issue warnings, though, of course, those warnings can be ignored. I am hopeful these two warnings will be sufficient and we will not need make these

Re: [HACKERS] Bug with pg_basebackup and 'shared' tablespace

On 30/09/17 06:43, Robert Haas wrote: On Fri, Sep 29, 2017 at 2:06 AM, Michael Paquier wrote: My tendency about this patch is still that it should be rejected. This is presenting additional handling for no real gain. I vehemently disagree. If the server lets you create a tablespace, then ev

Re: [HACKERS] Horizontal scalability/sharding

On 01/09/15 21:41, Bruce Momjian wrote: Well, reworking our partitioning system is one of the things required for sharding, so at least we will clean up one mess while we create another. ;-) Seem my post to Josh Berkus just now --- I think if we don't use FDWs, that sharding is such a limited

Re: [HACKERS] proposal: hide application_name from other users

On 22/01/14 13:32, Harold Giménez wrote: On Tue, Jan 21, 2014 at 4:19 PM, Bruce Momjian wrote: On Tue, Jan 21, 2014 at 04:06:46PM -0800, Harold Giménez wrote: I don't know of a client where it can't be overridden. The friction occurs when by default it sets it to something useful to a develope

Re: [HACKERS] Why do we let autovacuum give up?

On 24/01/14 09:49, Tom Lane wrote: 2. What have you got that is requesting exclusive lock on pg_attribute? That seems like a pretty unfriendly behavior in itself. regards, tom lane I've seen this sort of problem where every db session was busily creating temporary tables. I never got to the

Re: [HACKERS] Why do we let autovacuum give up?

On 24/01/14 10:09, Robert Haas wrote: On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood wrote: On 24/01/14 09:49, Tom Lane wrote: 2. What have you got that is requesting exclusive lock on pg_attribute? That seems like a pretty unfriendly behavior in itself. regards, tom lane I've seen this

Re: [HACKERS] Why do we let autovacuum give up?

On 24/01/14 10:16, Mark Kirkwood wrote: On 24/01/14 10:09, Robert Haas wrote: On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood wrote: On 24/01/14 09:49, Tom Lane wrote: 2. What have you got that is requesting exclusive lock on pg_attribute? That seems like a pretty unfriendly behavior in

Re: [HACKERS] Why do we let autovacuum give up?

On 24/01/14 12:13, Jeff Janes wrote: On Thu, Jan 23, 2014 at 1:41 PM, Mark Kirkwood < mark.kirkw...@catalyst.net.nz> wrote: On 24/01/14 10:16, Mark Kirkwood wrote: On 24/01/14 10:09, Robert Haas wrote: On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood wrote: On 24/01/14 09:49, To

Re: [HACKERS] Why do we let autovacuum give up?

On 24/01/14 12:28, Mark Kirkwood wrote: On 24/01/14 12:13, Jeff Janes wrote: On Thu, Jan 23, 2014 at 1:41 PM, Mark Kirkwood < mark.kirkw...@catalyst.net.nz> wrote: On 24/01/14 10:16, Mark Kirkwood wrote: On 24/01/14 10:09, Robert Haas wrote: On Thu, Jan 23, 2014 at 4:03 PM, Mark Ki

Re: [HACKERS] Add pgbench option: CHECKPOINT before starting benchmark

On 30/08/13 19:54, KONDO Mitsumasa wrote: > Hi, > > I add checkpoint option to pgbench. > > pgbench is simple and useful benchmark for every user. However, result of > benchmark greatly changes by some situations which are in executing > checkpoint, > number of dirty buffers in share_buffers, an

Re: [HACKERS] [PoC] pgstattuple2: block sampling to reduce physical read

On 16/09/13 16:20, Satoshi Nagayasu wrote: > (2013/09/15 11:07), Peter Eisentraut wrote: >> On Sat, 2013-09-14 at 16:18 +0900, Satoshi Nagayasu wrote: >>> I'm looking forward to seeing more feedback on this approach, >>> in terms of design and performance improvement. >>> So, I have submitted this

Re: [HACKERS] [PoC] pgstattuple2: block sampling to reduce physical read

On 11/10/13 11:09, Mark Kirkwood wrote: > On 16/09/13 16:20, Satoshi Nagayasu wrote: >> (2013/09/15 11:07), Peter Eisentraut wrote: >>> On Sat, 2013-09-14 at 16:18 +0900, Satoshi Nagayasu wrote: >>>> I'm looking forward to seeing more feedback on this ap

Re: [HACKERS] [PoC] pgstattuple2: block sampling to reduce physical read

On 11/10/13 17:08, Satoshi Nagayasu wrote: > (2013/10/11 7:32), Mark Kirkwood wrote: >> On 11/10/13 11:09, Mark Kirkwood wrote: >>> On 16/09/13 16:20, Satoshi Nagayasu wrote: >>>> (2013/09/15 11:07), Peter Eisentraut wrote: >>>>> On Sat, 2013

Re: [HACKERS] [PoC] pgstattuple2: block sampling to reduce physical read

On 11/10/13 17:33, Jaime Casanova wrote: On Thu, Oct 10, 2013 at 5:32 PM, Mark Kirkwood wrote: Quietly replying to myself - looking at the code the sampler does 3000 random page reads... FWIW, something that bothers me is that there is 3000 random page reads... i mean, why 3000? how do you

Re: [HACKERS] [PoC] pgstattuple2: block sampling to reduce physical read

On 11/10/13 17:49, Mark Kirkwood wrote: > On 11/10/13 17:08, Satoshi Nagayasu wrote: >> (2013/10/11 7:32), Mark Kirkwood wrote: >>> On 11/10/13 11:09, Mark Kirkwood wrote: >>>> On 16/09/13 16:20, Satoshi Nagayasu wrote: >>>>> (2013/09/15 11:07), Peter E

Re: [HACKERS] [PoC] pgstattuple2: block sampling to reduce physical read

On 11/10/13 17:33, Jaime Casanova wrote: also the name pgstattuple2, doesn't convince me... maybe you can use pgstattuple() if you use a second argument (percentage of the sample) to overload the function +1, that seems much nicer. Regards Mark -- Sent via pgsql-hackers mailing list (pgsq

Re: [HACKERS] ERROR : 'tuple concurrently updated'

On 18/10/13 18:01, Amit Kapila wrote: On Wed, Oct 16, 2013 at 5:55 PM, Stéphan BEUZE wrote: The following query is performed concurrently by two threads logged in with two different users: WITH raw_stat AS ( SELECT host(client_addr) as client_addr, pid ,

Re: [HACKERS] [PoC] pgstattuple2: block sampling to reduce physical read

On 16/10/13 11:51, Mark Kirkwood wrote: On 11/10/13 17:33, Jaime Casanova wrote: also the name pgstattuple2, doesn't convince me... maybe you can use pgstattuple() if you use a second argument (percentage of the sample) to overload the function +1, that seems much nicer. Oh - and i

Re: [HACKERS] Clean switchover

On 12/06/13 13:15, Stephen Frost wrote: * Fujii Masao (masao.fu...@gmail.com) wrote: The attached patch fixes this problem. It just changes walsender so that it waits for all the outstanding WAL records to be replicated to the standby before closing the replication connection. Seems like a goo

Re: [HACKERS] Clean switchover

On 14/06/13 07:38, Fujii Masao wrote: On Wed, Jun 12, 2013 at 12:55 PM, Mark Kirkwood wrote: On 12/06/13 13:15, Stephen Frost wrote: * Fujii Masao (masao.fu...@gmail.com) wrote: The attached patch fixes this problem. It just changes walsender so that it waits for all the outstanding WAL

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On 25/06/13 03:54, Joshua D. Drake wrote: It is mentioned. Of course now I can't find it but it is there. However, I believe you are taking the wrong perspective on this. This is not a shame wall. It is a transparent reminder of the policy and those who have not assisted in reviewing a patch b

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On 25/06/13 15:56, Tom Lane wrote: Mark Kirkwood writes: One of the reasons for fewer reviewers than submitters, is that it is a fundamentally more difficult job. I've submitted a few patches in a few different areas over the years - however if I grab a patch on the queue that is n

Re: [HACKERS] Kudos for Reviewers -- straw poll

On 27/06/13 07:12, Josh Berkus wrote: On 06/26/2013 12:02 PM, Alvaro Herrera wrote: See the entry for foreign key locks: Prevent non-key-field row updates from locking foreign key rows (Álvaro Herrera, Noah Misch, Andres Freund, Alexander Shulgin, Marti Raudsepp) I am the author of most

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On 04/07/13 10:43, Robert Haas wrote: And people who submit patches for review should also review patches: they are asking other people to do work, so they should also contribute work. I think that is an overly simplistic view of things. People submit patches for a variety of reasons, but ty

Re: [HACKERS] Remove fsync ON/OFF as a visible option?

On 21/03/15 19:28, Jaime Casanova wrote: On Fri, Mar 20, 2015 at 11:29 PM, Michael Paquier wrote: On Sat, Mar 21, 2015 at 2:47 AM, Peter Geoghegan wrote: On Fri, Mar 20, 2015 at 9:52 AM, Joshua D. Drake wrote: There are just as many people that are running with scissors that are now running

Re: [HACKERS] Remove fsync ON/OFF as a visible option?

On 22/03/15 08:14, Jaime Casanova wrote: El mar 21, 2015 2:00 AM, "Mark Kirkwood" mailto:mark.kirkw...@catalyst.net.nz>> escribió: > > On 21/03/15 19:28, Jaime Casanova wrote: >> >> what about not removing it but not showing it in postgresql.conf? as a >

Re: [HACKERS] Streaming replication

On 31/03/15 12:45, Tatsuo Ishii wrote: > In the doc: > > 25.2.5. Streaming Replication > : > The standby connects to the primary, which streams WAL records to the > standby as they're generated, without waiting for the WAL file to be > filled. > > This seems to claim that walsender sends WAL file

Re: [HACKERS] Trove with PostgreSQL-XC

On 19/08/14 23:14, Vivek Singh Raghuwanshi wrote: Hi All, Please let me know is that possible to use Openstack Trove with Postgres-XC. With instances and Baremetal (after Juno Release). I Know it is possible to use other medium like MySQL or PostgreSQL, but i am not sure about XC. AFAIK [1],

Re: [HACKERS] Per table autovacuum vacuum cost limit behaviour strange

On 27/08/14 10:27, Alvaro Herrera wrote: Alvaro Herrera wrote: So my proposal is a bit more complicated. First we introduce the notion of a single number, to enable sorting and computations: the "delay equivalent", which is the cost_limit divided by cost_delay. Here's a patch that implements

Re: [HACKERS] Per table autovacuum vacuum cost limit behaviour strange

On 27/08/14 10:27, Alvaro Herrera wrote: Alvaro Herrera wrote: So my proposal is a bit more complicated. First we introduce the notion of a single number, to enable sorting and computations: the "delay equivalent", which is the cost_limit divided by cost_delay. Here's a patch that implements

Re: [HACKERS] Per table autovacuum vacuum cost limit behaviour strange

On 29/08/14 08:56, Alvaro Herrera wrote: Robert Haas wrote: I agree that you might not like that. But you might not like having the table vacuumed slower than the configured rate, either. My impression is that the time between vacuums isn't really all that negotiable for some people. I had o

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 15:46, Craig Ringer wrote: was "is exactly why we need a new language" and that "All the clumsy stuff we cannot fix in plpgsql, can easily be fixed in plpgsql2, with the most beautiful syntax we can come up with." But you haven't said HOW you propose to fix this one case. Unfortuna

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 21:25, Álvaro Hernández Tortosa wrote: On 02/09/14 05:24, Craig Ringer wrote: I couldn't disagree more. If we were to implement anything, it'd be PL/PSM (http://en.wikipedia.org/wiki/SQL/PSM). I'm sure it's as bizarre and quirky as anything else the SQL committee has brought forth,

Re: [HACKERS] Scaling shared buffer eviction

On 03/09/14 16:22, Amit Kapila wrote: On Wed, Sep 3, 2014 at 9:45 AM, Amit Kapila wrote: On Thu, Aug 28, 2014 at 4:41 PM, Amit Kapila wrote: I have yet to collect data under varying loads, however I have collected performance data for 8GB shared buffers which shows reasonably good performa

Re: [HACKERS] Scaling shared buffer eviction

On 04/09/14 14:42, Amit Kapila wrote: On Thu, Sep 4, 2014 at 8:00 AM, Mark Kirkwood wrote: Hi Amit, Results look pretty good. Does it help in the read-write case too? Last time I ran the tpc-b test of pgbench (results of which are posted earlier in this thread), there doesn't seem

Re: [HACKERS] Scaling shared buffer eviction

On 05/09/14 23:50, Amit Kapila wrote: On Fri, Sep 5, 2014 at 8:42 AM, Mark Kirkwood mailto:mark.kirkw...@catalyst.net.nz>> wrote: > > On 04/09/14 14:42, Amit Kapila wrote: >> >> On Thu, Sep 4, 2014 at 8:00 AM, Mark Kirkwood mailto:mark.kirkw...@cat

Re: [HACKERS] Scaling shared buffer eviction

On 10/09/14 18:54, Amit Kapila wrote: On Wed, Sep 10, 2014 at 5:46 AM, Mark Kirkwood mailto:mark.kirkw...@catalyst.net.nz>> wrote: > > In terms of the effect of the patch - looks pretty similar to the scale 2000 results for read-write, but read-only is a different and more inter

Re: [HACKERS] Postgres code for a query intermediate dataset

On 14/09/14 05:36, Rohit Goyal wrote: Hi All, I want to work on the code of intermediate dataset of select and update query. For example. Rohit's salary has been updated 4 times, so it has 4 different version of salary. I want to select salary of person named Rohit. Now suppose , in intermed

Re: [HACKERS] Scaling shared buffer eviction

On 14/09/14 19:00, Amit Kapila wrote: On Fri, Sep 12, 2014 at 11:09 PM, Gregory Smith mailto:gregsmithpg...@gmail.com>> wrote: > This looks like it's squashed one of the very fundamental buffer > scaling issues though; well done Amit. Thanks. > I'll go back to my notes and try to recreate

Re: [HACKERS] Postgres code for a query intermediate dataset

On 14/09/14 19:25, Atri Sharma wrote: On Sunday, September 14, 2014, Mark Kirkwood mailto:mark.kirkw...@catalyst.net.nz>> wrote: On 14/09/14 05:36, Rohit Goyal wrote: Hi All, I want to work on the code of intermediate dataset of select and update

Re: [HACKERS] Postgres code for a query intermediate dataset

On 14/09/14 20:24, Atri Sharma wrote: On Sun, Sep 14, 2014 at 1:30 PM, Mark Kirkwood mailto:mark.kirkw...@catalyst.net.nz>> wrote: On 14/09/14 19:25, Atri Sharma wrote: On Sunday, September 14, 2014, Mark Kirkwood mailto:mark.kirkw...@catalyst.

Re: [HACKERS] Postgres code for a query intermediate dataset

On 14/09/14 20:11, Rohit Goyal wrote: Hi Mark, On Sun, Sep 14, 2014 at 8:57 AM, Mark Kirkwood mailto:mark.kirkw...@catalyst.net.nz>> wrote: Currently in Postgres, these intermediate versions all exist - however a given session can only see one of them. Also VACUUM is allo

Re: [HACKERS] Postgres code for a query intermediate dataset

On 14/09/14 21:18, Rohit Goyal wrote: Hi Mark & Atri, :) Thanks for reply. But, I think i confused you. I am talking about access using indexes. So, I assume that B+ tree store key-value pair where rohit is the key and all the versions are its value. Another way to think is I have a secondary i

  1   2   3   4   5   6   >