Re: [HACKERS] [PATCH]Tablesample Submission
On 17 May 2013 21:46, Jaime Casanova wrote: > On Sun, Nov 4, 2012 at 10:22 PM, Qi Huang wrote: >> Dear hackers >> Sorry for not replying the patch review. I didn't see the review until >> recently as my mail box is full of Postgres mails and I didn't notice the >> one for me, my mail box configuration problem. >> I am still kind of busy with my university final year project. I shall >> not have time to work on updating the patch until this semester finishes >> which is December. I will work on then. > Should we expect an updated patch for next commitfest? This was added to CF1 of 9.4. The patch is nowhere near committable and hasn't been worked on at all since last time it was submitted. It's important that we have an efficient implementation of TABLESAMPLE in Postgres. I'm going to remove it from CF, for now, but I'll also take responsibility for this for 9.4, barring objections. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Running pgindent
Do we want to run pgindent soon? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Add more regression tests for CREATE OPERATOR
Hi, Please find attached a patch to take code-coverage of CREATE OPERATOR (src/backend/commands/operatorcmds.c) from 56% to 91%. Any and all feedback is welcome. -- Robins Tharakan regress_createoperator.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] WAL segments (names) not in a sequence
A PostgreSQL user recently reported on pgsql-admin about an issue: when he changed wal_level from 'minimal' to 'hot_standby', the WAL segment sequence rewound, that is, it started using old names. A snippet of his "ls -lrt pg_xlog": -rw--- 1 postgres postgres 16777216 May 21 12:13 0001000F00B3 -rw--- 1 postgres postgres 16777216 May 21 12:13 0001001A -rw--- 1 postgres postgres 16777216 May 21 12:13 000100100036 -rw--- 1 postgres postgres 16777216 May 21 12:13 00010018 -rw--- 1 postgres postgres 16777216 May 21 12:13 0001000F00F6 -rw--- 1 postgres postgres 16777216 May 21 12:13 0001000F00E4 -rw--- 1 postgres postgres 16777216 May 21 12:13 0001000F00F2 -rw--- 1 postgres postgres 16777216 May 21 12:13 00010013 -rw--- 1 postgres postgres 16777216 May 21 12:13 0001000F00D5 -rw--- 1 postgres postgres 16777216 May 21 12:13 0001000F00A9 -rw--- 1 postgres postgres 16777216 May 21 12:13 0001000F00D6 -rw--- 1 postgres postgres 16777216 May 21 12:13 00010010004E -rw--- 1 postgres postgres 16777216 May 21 12:13 0001000F00D8 -rw--- 1 postgres postgres 16777216 May 21 12:13 0001000F00B4 -rw--- 1 postgres postgres 16777216 May 21 12:13 0001000F00BA -rw--- 1 postgres postgres 16777216 May 21 12:13 0001000F00C3 -rw--- 1 postgres postgres 16777216 May 21 12:13 000100100071 -rw--- 1 postgres postgres 16777216 May 21 12:13 000100100047 -rw--- 1 postgres postgres 16777216 May 21 12:13 000100100026 # WAL after wal_level changed from 'minimal' to 'hot_standby' -rw--- 1 postgres postgres 16777216 May 21 12:27 0001000E007B -rw--- 1 postgres postgres 16777216 May 21 12:35 0001000E007C -rw--- 1 postgres postgres 276 May 21 12:35 0001000E007C.0020.backup -rw--- 1 postgres postgres 16777216 May 21 14:53 0001000E007D -rw--- 1 postgres postgres 16777216 May 21 14:53 0001000E007E -rw--- 1 postgres postgres 16777216 May 21 14:53 0001000E007F -rw--- 1 postgres postgres 16777216 May 21 14:53 0001000E0080 Is this a known issue? -- Amit Langote -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MVCC catalog access
On Tue, May 21, 2013 at 10:18 PM, Robert Haas wrote: > [ MVCC catalog access seems to be pretty cheap ] In discussions today, Tom Lane suggested testing the time to start up a backend and run a simple query such as "SELECT 2+2" in the absence of a relcache file. I did this and can't measure any overhead as a result of MVCC catalog access. I tried it with no active connections. I tried it with 600 idle active connections (to make taking MVCC snapshots more expensive). I couldn't quite believe it made no difference, so I tried doing it in a tight loop under pgbench. I still can't measure any difference. I haven't tested carefully enough to rule out the possibility of an effect <1/2% at 600 connections, but there certainly isn't anything bigger than that and I don't even think there's that much of a difference. Andres Freund suggested creating a couple of simple tables and having lots of short-lived backends select data from them. rhaas=# create table af1 (x) as select g from generate_series(1,4) g; SELECT 4 rhaas=# create table af2 (x) as select g from generate_series(4,7) g; SELECT 4 Test query: SELECT * FROM af1, af2 WHERE af1.x = af2.x; pgbench command: pgbench -T 10 -c 50 -j 50 -n -f f -C With mvcc_catalog_access=off, I get ~1553 tps; with it on, I get ~1557 tps. Hmm... that could be because of the two-line debugging hunk my patch addes to HeapTupleSatisfiesNow(). After removing that, I get maybe a 1% regression with mvcc_catalog_access=on on this test, but it's not very consistent. If I restart the database server a few times, the overhead bounces around each time, and sometimes it's zero; the highest I saw is 1.4%. But it's not much, and this is a pretty brutal workload for PostgreSQL, since starting up >1500 connections per second is not a workload for which we're well-suited in the first place. All in all, I'm still feeling optimistic. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Running pgindent
On Wed, May 22, 2013 at 1:52 PM, Bruce Momjian wrote: > Do we want to run pgindent soon? +1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MVCC catalog access
On 2013-05-22 22:51:13 -0400, Robert Haas wrote: > In discussions today, Tom Lane suggested testing the time to start up > a backend and run a simple query such as "SELECT 2+2" in the absence > of a relcache file. > I did this and can't measure any overhead as a result of MVCC catalog > access. I tried it with no active connections. I tried it with 600 > idle active connections (to make taking MVCC snapshots more > expensive). Did you try it with the 600 transactions actually being in a transaction and having acquired a snapshot? > All in all, I'm still feeling optimistic. +1. I still feel like this has to be much harder since we made it out to be hard for a long time ;) Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Heap truncation without AccessExclusiveLock (9.4)
On Mon, May 20, 2013 at 10:19 AM, Heikki Linnakangas wrote: >> It shouldn't be difficult to restrict the set of backends that have to >> be signaled to those that have the relation open. You could have a >> special kind of catchup signal that means "catch yourself up, but >> don't chain" > > What does "chain" mean above? Normally, when sinval catchup is needed, we signal the backend that is furthest behind. After catching up, it signals the backend that is next-furthest behind, which in turns catches up and signals the next laggard, and so forth. > Hmm. The sinval message makes sure that when a backend locks a relation, it > will see the latest value, because of the AcceptInvalidationMessages call in > LockRelation. If there is no sinval message, you'd need to always check the > shared memory area when you lock a relation. The latest value of what? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MVCC catalog access
On Wed, May 22, 2013 at 11:02 PM, Andres Freund wrote: > On 2013-05-22 22:51:13 -0400, Robert Haas wrote: >> In discussions today, Tom Lane suggested testing the time to start up >> a backend and run a simple query such as "SELECT 2+2" in the absence >> of a relcache file. > >> I did this and can't measure any overhead as a result of MVCC catalog >> access. I tried it with no active connections. I tried it with 600 >> idle active connections (to make taking MVCC snapshots more >> expensive). > > Did you try it with the 600 transactions actually being in a transaction > and having acquired a snapshot? No... I can hack something up for that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MVCC catalog access
On 2013-05-22 23:05:40 -0400, Robert Haas wrote: > On Wed, May 22, 2013 at 11:02 PM, Andres Freund > wrote: > > On 2013-05-22 22:51:13 -0400, Robert Haas wrote: > >> In discussions today, Tom Lane suggested testing the time to start up > >> a backend and run a simple query such as "SELECT 2+2" in the absence > >> of a relcache file. > > > >> I did this and can't measure any overhead as a result of MVCC catalog > >> access. I tried it with no active connections. I tried it with 600 > >> idle active connections (to make taking MVCC snapshots more > >> expensive). > > > > Did you try it with the 600 transactions actually being in a transaction > > and having acquired a snapshot? > > No... I can hack something up for that. Make that actually having acquired an xid. We skip a large part of the work if a transaction doesn't yet have one afair. I don't think the mere presence of 600 idle connections without an xid in contrast to just having max_connection at 600 should actually make a difference in the cost of acquiring a snapshot? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
