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] 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] 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] 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] 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] 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] 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 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

[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] 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] 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] 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] 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] 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 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 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 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 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 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 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 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 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

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

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

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

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 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

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 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] 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.

[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] UNDO and in-place update

On 23/11/16 16:31, Tom Lane wrote: Robert Haas writes: [ Let's invent Oracle-style UNDO logs ] I dunno. I remember being told years ago, by an ex-Oracle engineer, that he thought our approach was better. I don't recall all the details of the conversation but I think his key point was basica

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

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 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

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] 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] 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 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] 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 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] 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] 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 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 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

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 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

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 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 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 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 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] Btree Index on PostgreSQL and Wiredtiger (MongoDB3.2)

On 13/08/16 05:44, Jeff Janes wrote: On Fri, Aug 12, 2016 at 1:40 AM, Mark Kirkwood However your index rebuild gets you from 5 to 3 GB - does that really help performance significantly? It can make a big difference, depending on how much RAM you have. Yeah - I suspect this is the issue

Re: [HACKERS] Btree Index on PostgreSQL and Wiredtiger (MongoDB3.2)

After examining the benchmark design - I see we are probably not being helped by the repeated insertion of keys all of form 'userxxx' leading to some page splitting. However your index rebuild gets you from 5 to 3 GB - does that really help performance significantly? regards Mark On 11

Re: [HACKERS] Why we lost Uber as a user

On 03/08/16 02:27, Robert Haas wrote: Personally, I think that incremental surgery on our current heap format to try to fix this is not going to get very far. If you look at the history of this, 8.3 was a huge release for timely cleanup of dead tuple. There was also significant progress in 8.4

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 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] 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] 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] pg_xlog -> pg_xjournal?

On 01/06/15 05:29, Joel Jacobson wrote: While anyone who is familiar with postgres would never do something as stupid as to delete pg_xlog, according to Google, there appears to be a fair amount of end-users out there having made the irrevocable mistake of deleting the precious directory, a decis

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] 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] 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] a fast bloat measurement tool (was Re: Measuring relation free space)

On 26/02/15 13:32, Simon Riggs wrote: On 25 February 2015 at 23:30, Jim Nasby wrote: That said, I don't want to block this; I think it's useful. Though, perhaps it would be better as an extension instead of in contrib? I don't think it should be very version dependent? The whole point of thi

Re: [HACKERS] Unable to build pg_rewind

On 25/02/15 12:47, Michael Paquier wrote: On Wed, Feb 25, 2015 at 8:03 AM, Mark Kirkwood mailto:mark.kirkw...@catalyst.net.nz>> wrote: On 25/02/15 11:06, Ratay, Steve wrote: I have checked out the pg_rewind code from https://github.com/vmware/pg_rewind.git on the

Re: [HACKERS] Unable to build pg_rewind

On 25/02/15 11:06, Ratay, Steve wrote: I have checked out the pg_rewind code from https://github.com/vmware/pg_rewind.git on the master branch and am using PostgreSQL 9.4.1 source code to build against. When I try to compile pg_rewind, I am getting the following errors. How can I resolve the

Re: [HACKERS] List of table names of a DB

Actually, code has moved to: https://github.com/snaga/pqc On 09/01/15 19:53, Mark Kirkwood wrote: Also see: https://code.google.com/p/pqc/ A project to implement a query cache using pgpool code, probably lots of good ideas there. Cheers Mark On 09/01/15 19:38, Tatsuo Ishii wrote: Hi

Re: [HACKERS] List of table names of a DB

Also see: https://code.google.com/p/pqc/ A project to implement a query cache using pgpool code, probably lots of good ideas there. Cheers Mark On 09/01/15 19:38, Tatsuo Ishii wrote: Hi, pgpool-II (pgpool.net) does exactly the same thing. It receive SELECT query from clients, 1) parse it

Re: [HACKERS] Turning recovery.conf into GUCs

On 06/01/15 18:57, Josh Berkus wrote: On 01/05/2015 05:43 PM, Peter Eisentraut wrote: I have previously argued for a different approach: Ready recovery.conf as a configuration file after postgresql.conf, but keep it as a file to start recovery. That doesn't break any old workflows, it gets yo

Re: [HACKERS] mysql with postgres

On 23/12/14 22:36, Ravi Kiran wrote: hi all, Is postgres source code compatible with mysql database?? If it is, could someone could give me some links so that I can do that. I want to hack into the postgres source code, but as I am comfortable with mysql, I want to use the mysql database not p

Re: [HACKERS] Commitfest problems

On 20/12/14 11:22, Joshua D. Drake wrote: On 12/19/2014 12:28 AM, Mark Kirkwood wrote: To me that's a bit over the top stereotyping. +1 Having been mentioned one or two times myself - it was an unexpected "wow - cool" rather than a grumpy/fragile "I must be noticed&

Re: [HACKERS] Commitfest problems

On 19/12/14 20:48, Andres Freund wrote: On 2014-12-18 10:02:25 -0800, Joshua D. Drake wrote: I think a lot of hackers forget exactly how tender their egos are. Now I say this knowing that a lot of them will go, "Oh give me a break" but as someone who employs hackers, deals with open source AND n

Re: [HACKERS] Commitfest problems

On 13/12/14 22:37, Craig Ringer wrote: On 12/12/2014 06:02 AM, Josh Berkus wrote: Speaking as the originator of commitfests, they were *always* intended to be a temporary measure, a step on the way to something else like continuous integration. I'd really like to see the project revisit some

Re: [HACKERS] Vitesse DB call for testing

On 18/10/14 07:13, Josh Berkus wrote: CK, Before we go any further on this, how is Vitesse currently licensed? last time we talked it was still proprietary. If it's not being open-sourced, we likely need to take discussion off this list. +1 Guys, you need to 'fess up on the licensing! Rega

Re: [HACKERS] Fixed xloginsert_locks for 9.4

On 04/10/14 12:10, Bruce Momjian wrote: On Sat, Oct 4, 2014 at 12:00:36PM +1300, Mark Kirkwood wrote: I don't think we can offer absolutely accurate tuning advice, but I'm sure we can give some guidance. Let me try. +1 I think it is ok to document our reason for providing t

Re: [HACKERS] Fixed xloginsert_locks for 9.4

On 04/10/14 11:21, Andres Freund wrote: On 2014-10-03 18:16:28 -0400, Bruce Momjian wrote: On Sat, Oct 4, 2014 at 12:13:00AM +0200, Andres Freund wrote: Do we really want to expose a setting a few of us _might_ ask customers to change? They also will try that themselves. Our customers aren't

Re: [HACKERS] “Core” function in Postgres

On 24/09/14 11:29, Mingzhe Li wrote: Hi experts, I want to know what's the "core" function used in Postgres server? I am looking for something corresponding to main() in a simple C program. I want to know the file path and the function name. I am using Postgres 9.3.5, however I assume the "core"

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

On 14/09/14 20:43, Mark Kirkwood wrote: On 14/09/14 20:24, Atri Sharma wrote: How do you plan to do all that VACUUM does for this table then? It seems to me that you are saying to VACUUM that it need not be concerned with table 'A' and you are assuming ownership of all the tasks pe

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

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 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 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] 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 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 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] 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 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 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] proposal: Set effective_cache_size to greater of .conf value, shared_buffers

On 07/05/14 17:35, Peter Geoghegan wrote: On Tue, May 6, 2014 at 10:20 PM, Simon Riggs wrote: On 6 May 2014 23:47, Josh Berkus wrote: If you're going to make an argument in favor of different tuning advice, then do it based on something in which you actually believe, based on hard evidence.

  1   2   3   4   5   6   >