Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/09/11 6:02, Robert Haas wrote: On Thu, Sep 3, 2015 at 6:25 AM, Etsuro Fujita wrote: I gave it another thought; the following changes to ExecInitNode would make the patch much simpler, ie, we would no longer need to call the new code in ExecInitForeignScan,

Re: [HACKERS] pageinspect patch, for showing tuple data

On Fri, Sep 11, 2015 at 12:08 AM, Nikolay Shaplov wrote: > В письме от 10 сентября 2015 15:46:25 пользователь Michael Paquier написал: > >> > So if move tuple data parsing into separate function, then we have to pass >> > these values alongside the tuple data. This is

Re: [HACKERS] pageinspect patch, for showing tuple data

On Fri, Sep 11, 2015 at 12:12 AM, Bruce Momjian wrote: > On Thu, Sep 10, 2015 at 03:46:25PM +0900, Michael Paquier wrote: >> Why is it not convenient at all? Yes, you have a point, we need those >> fields to be able to parse the t_data properly. Still the possibility >> to show

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> -Original Message- > From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp] > Sent: Friday, September 11, 2015 12:36 PM > To: Robert Haas > Cc: Kaigai Kouhei(海外 浩平); PostgreSQL-development; 花田茂 > Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual > > On 2015/09/11 6:24,

Re: Hooking at standard_join_search (Was: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual)

On 2015/09/11 6:30, Robert Haas wrote: On Wed, Sep 9, 2015 at 2:30 AM, Etsuro Fujita wrote: But that path might have already been discarded on the basis of cost. I think Tom's idea is better: let the FDW consult some state cached for this purpose in the RelOptInfo.

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 3 September 2015 at 05:10, Andres Freund wrote: > > +/* > > + * pg_int2str > > + * Converts 'value' into a decimal string representation of > the number. > > + * > > + * Caller must ensure that 'str' points to enough memory to hold the > result > > + * (at least

Re: [HACKERS] Multi-column distinctness.

On 09/07/2015 05:25 AM, Kyotaro HORIGUCHI wrote: Hello, but making the COLUMN required is certainly much worse as it breaks many existing scripts. The keyword inky breaks cases that manipulate "statistics" column. Ouch! It is simply by accident, or my lack of carefulness. I will come up

Re: [HACKERS] Small patch to fix an O(N^2) problem in foreign keys

Jan Wieck wrote: >>> The patch uses a heuristic method of detecting when the hash table >>> should be destroyed and recreated. InvalidateConstraintCacheCallBack() >>> adds the current size of the hash table to a counter. When that sum >>> reaches 1,000,000, the hash table is

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 2015-09-12 04:00:26 +1200, David Rowley wrote: > I've not done anything yet to remove the #ifdef HAVE_INT64_TIMESTAMP from > AppendSeconds(). The only way I can think to handle this is to just > make fsec_t unconditionally an int64 (since with float datetimes the > precision is 10 decimal

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 11 September 2015 at 22:23, YUriy Zhuravlev wrote: > > Without patch we have 417523 TPS and with patch 965821 TPS for big x86 > server. > All details here: https://gist.github.com/stalkerg/773a81b79a27b4d5d63f > > Impressive! I've run this on a single CPU server

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Friday 11 September 2015 18:14:21 Andres Freund wrote: > This way we can leave the for (;;) loop > in BufferAlloc() thinking that the buffer is unused (and can't be further > pinned because of the held spinlock!) We lost lock after PinBuffer_Locked in BufferAlloc. Therefore, in essence,

Re: Hooking at standard_join_search (Was: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual)

On Fri, Sep 11, 2015 at 3:12 AM, Etsuro Fujita wrote: > So, information to address the how-to-build-the-query-text > problem would be stored in the state, in other words. Right? Right. >> I am not sure what to do about parameterizations. That's one of my >>

[HACKERS] New gist vacuum.

Hello. I am student from gsoc programm.My project is sequantial access in vacuum of gist. New vacuum has 2 big step:physical order scan pages and cleaning after 1 step. 1 scan - scan all pages and create information map(hashmap) and add information to rescan stack( stack of pages that needed to

Re: [HACKERS] DBT-3 with SF=20 got failed

On Fri, Sep 11, 2015 at 1:12 PM, Tomas Vondra wrote: > I'm arguing for fixing the existing bug, and then addressing the case of > over-estimation separately, with proper analysis. Well, this is part of how we're looking it differently. I think the bug is "we're

Re: [HACKERS] Bad row estimation with indexed func returning bool

Jehan-Guillaume de Rorthais writes: > I faced a correlation problem on a query today and tried the usual trick > consisting of using an functional index and rewriting the query to use it. The core reason this isn't doing anything useful is that clause_selectivity() is hard-wired

Re: [HACKERS] Partitioned checkpointing

Hi, Partitioned checkpoint have the significant disadvantage that it increases random write io by the number of passes. Which is a bad idea, *especially* on SSDs. > >So we'd need logic like this > >1. Run through shared buffers and analyze the files contained in there > >2. Assign files to one

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2015-09-11 19:33:26 +0300, YUriy Zhuravlev wrote: > On Friday 11 September 2015 18:14:21 Andres Freund wrote: > > This way we can leave the for (;;) loop > > in BufferAlloc() thinking that the buffer is unused (and can't be further > > pinned because of the held spinlock!) > > We lost lock

Re: [HACKERS] RLS open items are vague and unactionable

Dean Rasheed writes: > On 11 September 2015 at 15:49, Tom Lane wrote: >> However, I don't see why UPDATE/DELETE with RETURNING couldn't be >> restricted according to *both* the UPDATE and SELECT policies, >> ie if there's RETURNING then you can't

Re: [HACKERS] RLS open items are vague and unactionable

On 11 September 2015 at 17:56, Tom Lane wrote: > Dean Rasheed writes: >> On 11 September 2015 at 15:49, Tom Lane wrote: >>> However, I don't see why UPDATE/DELETE with RETURNING couldn't be >>> restricted according to *both* the

Re: [HACKERS] Waits monitoring

On Thu, Sep 10, 2015 at 3:43 AM, Kyotaro HORIGUCHI wrote: > Generated lwlocknames.[ch] don't have header comment because > generate-lwlocknames.pl writes them into wrong place. > > lmgr/Makefile looks to have some mistakes. Fixed. > - lwlocknames.c is not

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

Hi, On 2015-09-11 13:23:24 +0300, YUriy Zhuravlev wrote: > Continuing the theme: > http://www.postgresql.org/message-id/3368228.mTSz6V0Jsq@dinodell Please don't just start new threads for a new version of the patch. > This time, we fairly rewrote 'refcount' and 'usage_count' to atomic in >

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 11 September 2015 at 15:43, Syed, Rahila wrote: > > Hello, > > Please find attached updated VACUUM progress checker patch. > Following have been accomplished in the patch > > 1. Accounts for index pages count while calculating total progress of > VACUUM. > 2. Common

Re: [HACKERS] Partitioned checkpointing

Hello Simon, The idea to do a partial pass through shared buffers and only write a fraction of dirty buffers, then fsync them is a good one. Sure. The key point is that we spread out the fsyncs across the whole checkpoint period. Yes, this is really Andres suggestion, as I understood it.

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Friday 11 September 2015 18:37:00 you wrote: > so unless I'm missing something, no, we haven't lost the lock. This section is protected by like LWLockAcquire(newPartitionLock, LW_EXCLUSIVE); before it (and we can't get this buffer from hash table). -- YUriy Zhuravlev Postgres Professional:

[HACKERS] Review: check existency of table for -t option (pg_dump) when pattern...

https://commitfest.postgresql.org/6/201/ Patch looks good and is helpful in some usecases. I found and fix some typo (new version in attach), but patch shows some inconsistent output: % pg_dump -t 'aaa*' postgres pg_dump: No matching tables were found % pg_dump -t 'aaa*' --strict-names

Re: [HACKERS] RLS open items are vague and unactionable

On 11 September 2015 at 15:49, Tom Lane wrote: > Dean Rasheed writes: >> Yeah, we had a similar discussion regarding UPDATE USING policies and >> ON CONFLICT UPDATE clauses. I think the argument against filtering is >> that the rows returned would

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Fri, Sep 11, 2015 at 3:08 AM, Etsuro Fujita wrote: > IIRC, Horiguchi-san also pointed that out. Honestly, I also think that that > is weird, but IIUC, I think it can't hurt. What I was concerned about was > EXPLAIN, but EXPLAIN doesn't handle an EvalPlanQual

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2015-09-11 19:46:02 +0300, YUriy Zhuravlev wrote: > On Friday 11 September 2015 18:37:00 you wrote: > > so unless I'm missing something, no, we haven't lost the lock. > This section is protected by like LWLockAcquire(newPartitionLock, > LW_EXCLUSIVE); before it (and we can't get this buffer

Re: [HACKERS] Did we forget to unpin buf in function "revmap_physical_extend" ?

Jinyu Zhang wrote: > In function "revmap_physical_extend", should we add "ReleaseBuffer(buf);" > between line 438 and 439 ? > 422 else > 423 { > 424 if (needLock) > 425 LockRelationForExtension(irel, ExclusiveLock); > 426 > 427 buf = ReadBuffer(irel,

Re: [HACKERS] RLS open items are vague and unactionable

On 10 September 2015 at 21:48, Robert Haas wrote: > The open items list here: > > https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items > > Dean's latest round of RLS refactoring. This refactoring patch doesn't fix any behavioural issues. It is all about trying to

Re: [HACKERS] 9.3.9 and pg_multixact corruption

...and here it is ;) --On 10. September 2015 19:45:46 -0300 Alvaro Herrera wrote: > Anyway, can you please request pg_controldata to be run on the failed > cluster and paste it here? pg_control version number:937 Catalog version number:

Re: [HACKERS] Partitioned checkpointing

Hello Takashi-san, I wanted to do some tests with this POC patch. For this purpose, it would be nice to have a guc which would allow to activate or not this feature. Could you provide a patch with such a guc? I would suggest to have the number of partitions as a guc, so that choosing 1

Re: [HACKERS] [PATCH v2] GSSAPI encryption support

On Thu, Sep 10, 2015 at 4:27 PM, Michael Paquier wrote: > On Thu, Sep 10, 2015 at 1:44 AM, Robbie Harwood wrote: >> Michael Paquier writes: >> >>> On Wed, Sep 9, 2015 at 4:12 AM, Robbie Harwood wrote: Michael

Re: [HACKERS] snapshot too old, configured by time

I'm starting to read through this and have a few questions. Kevin Grittner wrote: > 4. Tests have been added. They are currently somewhat minimal, > since this is using a whole new technique for testing from any > existing committed tests -- I wanted to make sure that this > approach to testing

Re: [HACKERS] RLS open items are vague and unactionable

Dean Rasheed wrote: > Ultimately I think this will be an extremely rare case, probably more > likely to happen as a result of accidentally misconfigured policies. > But if that does happen, I'd rather have an error to alert me to the > fact, than to silently do nothing.

Re: [HACKERS] Comment update to pathnode.c

On Fri, Sep 11, 2015 at 6:22 AM, Etsuro Fujita wrote: > The comments for create_foreignscan_path says as follows, but that it's > now possible that the function is called by GetForeignJoinPaths, which > was added in 9.5. > > 1450 /* > 1451 * create_foreignscan_path >

Re: [HACKERS] Autonomous Transaction is back

On Thu, Sep 10, 2015 at 8:39 PM, Noah Misch wrote: > On Wed, Sep 09, 2015 at 10:04:01AM -0400, Robert Haas wrote: >> On Sun, Sep 6, 2015 at 1:56 AM, Noah Misch wrote: >> > What design principle(s) have you been using to decide how autonomous >> >

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

>This doesn't seem to compile Oh. It compiled successfully when applied on HEAD on my machine. Anyways, the OID is changed to 3309 in the attached patch. 3308 / 3309 both are part of OIDs in unused OID list. Thank you, Rahila Syed Vacuum_progress_checker_v2.patch Description: Binary data --

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Rahila Syed wrote: > >This doesn't seem to compile > Oh. It compiled successfully when applied on HEAD on my machine. Anyways, > the OID is changed to 3309 in the attached patch. 3308 / 3309 both are part > of OIDs in unused OID list. I think Thom may have patched on top of some other patch. --

Re: [HACKERS] jsonb_concat: make sure we always return a non-scalar value

On 09/09/2015 01:03 PM, Oskari Saarenmaa wrote: 09.09.2015, 18:53, Andrew Dunstan kirjoitti: On 09/08/2015 09:54 AM, Andrew Dunstan wrote: On 09/05/2015 02:47 AM, Oskari Saarenmaa wrote: There was a long thread about concatenating jsonb objects to each other, but that discussion didn't

Re: [HACKERS] Re: [PATCH] pg_upgrade fails when postgres/template1 isn't in default tablespace

On Thu, Sep 10, 2015 at 09:59:41PM -0400, Bruce Momjian wrote: > On Fri, Sep 11, 2015 at 12:41:09AM +, Hyongtae Lim wrote: > > The following review has been posted through the commitfest application: > > make installcheck-world: tested, passed > > Implements feature: tested, passed > >

Re: [HACKERS] Double linking MemoryContext children

Jan Wieck writes: > The attached script demonstrates an O(N^2) problem we recently became > aware of. The script simply executes a large anonymous code block that > doesn't do anything useful. Usage is > ./t1.py [NUM_STMTS] | psql [DBNAME] > NUM_STMTS defaults to 20,000.

Re: [HACKERS] Parser emits mysterious error message for very long tokens

Kyotaro HORIGUCHI writes: > Hello, this is a problem on an extreme situation. > When parser encounters very long tokens, it returns an error > message which should be mysterious for users. >> $ perl -e "print \"select '\" . \"x\"x(512*1024*1024) . \"'\"" | psql

[HACKERS] Double linking MemoryContext children

The attached script demonstrates an O(N^2) problem we recently became aware of. The script simply executes a large anonymous code block that doesn't do anything useful. Usage is ./t1.py [NUM_STMTS] | psql [DBNAME] NUM_STMTS defaults to 20,000. The code block executes rather fast, but the

Re: [HACKERS] RLS open items are vague and unactionable

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Sep 11, 2015 at 7:33 AM, Stephen Frost wrote: > > I've updated the page to add more details about the various items, > > though the only code changes at this point considered 'open' are this > > refactoring and

Re: [HACKERS] Double linking MemoryContext children

On 09/11/2015 09:38 AM, Tom Lane wrote: Jan Wieck writes: The attached script demonstrates an O(N^2) problem we recently became aware of. The script simply executes a large anonymous code block that doesn't do anything useful. Usage is ./t1.py [NUM_STMTS] | psql

Re: [HACKERS] Partitioned checkpointing

On 11 September 2015 at 09:07, Fabien COELHO wrote: > Some general comments : > Thanks for the summary Fabien. > I understand that what this patch does is cutting the checkpoint of > buffers in 16 partitions, each addressing 1/16 of buffers, and each with > its own

Re: [HACKERS] Double linking MemoryContext children

Jan Wieck writes: > On 09/11/2015 09:38 AM, Tom Lane wrote: >> Seems less invasive to fix SPI to delete in the opposite order? > That would assume that there are no other code paths that destroy memory > contexts out of LIFO order. Given that we've not seen this sort of

Re: [HACKERS] RLS open items are vague and unactionable

On 11 September 2015 at 13:05, Robert Haas wrote: > Thanks for the updates. My thoughts: > > On RETURNING, it seems like we've got a fairly fundamental problem > here. If I understand correctly, the intention of allowing policies > to be filtered by command type is to

Re: [HACKERS] CREATE POLICY and RETURNING

Zhaomo, * Zhaomo Yang (zmp...@gmail.com) wrote: > I admit that I gave some bad examples in the previous email, and it is fair > to say > this (Being able to have something like NEW.value > 10 OR OLD.id = 1) is > not a advantage of what I proposed > before I can come up with any real-world

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Fri, Sep 11, 2015 at 2:01 AM, Kouhei Kaigai wrote: > If a callback on ForeignRecheck processes EPQ rechecks, the core PostgreSQL > don't need to know what expression was pushed down and how does it kept in > the private field (fdw_exprs). Only FDW driver knows which

Re: [HACKERS] DBT-3 with SF=20 got failed

On 09/11/2015 07:16 PM, Robert Haas wrote: On Fri, Sep 11, 2015 at 1:12 PM, Tomas Vondra wrote: I'm arguing for fixing the existing bug, and then addressing the case of over-estimation separately, with proper analysis. Well, this is part of how we're looking

Re: [HACKERS] Partitioned checkpointing

Hello Andres, Thank you for discussion. It’s nice for me to discuss here. > Partitioned checkpoint have the significant disadvantage that it increases > random write io by the number of passes. Which is a bad idea, > *especially* on SSDs. I’m curious about the conclusion that the Partitioned

Re: [HACKERS] proposal: function parse_ident

Hi new update of parse_ident function patch Regards Pavel diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml new file mode 100644 index 22d4f61..1581d5a *** a/doc/src/sgml/func.sgml --- b/doc/src/sgml/func.sgml *** *** 1707,1712 --- 1707,1727

Re: [HACKERS] RLS open items are vague and unactionable

On Fri, Sep 11, 2015 at 7:33 AM, Stephen Frost wrote: > I've updated the page to add more details about the various items, > though the only code changes at this point considered 'open' are this > refactoring and the question regarding the 'row-level-security disabled' >

[HACKERS] Bad row estimation with indexed func returning bool

Hi, I faced a correlation problem on a query today and tried the usual trick consisting of using an functional index and rewriting the query to use it. However, after writing the function, indexing it and rewriting the query, I faced an optimizer behavior I was not expecting. I wrote a short

Re: [HACKERS] RLS open items are vague and unactionable

Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > On 10 September 2015 at 21:48, Robert Haas wrote: > > The open items list here: > > > > https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items > > > > Dean's latest round of RLS refactoring. > > This refactoring

[HACKERS] Move PinBuffer and UnpinBuffer to atomics

Hello hackers! Continuing the theme: http://www.postgresql.org/message-id/3368228.mTSz6V0Jsq@dinodell This time, we fairly rewrote 'refcount' and 'usage_count' to atomic in PinBuffer and UnpinBuffer (but save lock for buffer flags in Unpin). In the same time it doesn't affect to correctness

[HACKERS] Comment update to pathnode.c

Hi, The comments for create_foreignscan_path says as follows, but that it's now possible that the function is called by GetForeignJoinPaths, which was added in 9.5. 1450 /* 1451 * create_foreignscan_path 1452 *Creates a path corresponding to a scan of a foreign table, 1453 *returning

Re: [HACKERS] CREATE POLICY and RETURNING

> > I really don't like the approach you're suggesting above where an 'OR' > inside of > such a clause could mean that users can arbitrarly change any existing row > without any further check on that row and I have a hard time seeing the > use-case which justifies the additional complexity and

Re: [HACKERS] Partitioned checkpointing

Hi, > I understand that what this patch does is cutting the checkpoint > of buffers in 16 partitions, each addressing 1/16 of buffers, and each with > its own wal-log entry, pacing, fsync and so on. Right. However, > The key point is that we spread out the fsyncs across the whole

Re: [HACKERS] Partitioned checkpointing

Hello Fabien, > I wanted to do some tests with this POC patch. For this purpose, it would > be nice to have a guc which would allow to activate or not this feature. Thanks. > Could you provide a patch with such a guc? I would suggest to have the number > of partitions as a guc, so that choosing

Re: [HACKERS] Autonomous Transaction is back

On Fri, Sep 11, 2015 at 02:30:53PM -0500, Merlin Moncure wrote: > On Thu, Sep 10, 2015 at 8:39 PM, Noah Misch wrote: > > It's an exceptionally-challenging development project, agreed. So much code > > assumes the 1:1 relationship between backends and top-level transactions. >

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 11 September 2015 at 22:34, Alvaro Herrera wrote: > Rahila Syed wrote: > > >This doesn't seem to compile > > Oh. It compiled successfully when applied on HEAD on my machine. Anyways, > > the OID is changed to 3309 in the attached patch. 3308 / 3309 both are > part >

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Fri, Sep 11, 2015 at 9:21 PM, Robert Haas wrote: > > On Fri, Sep 11, 2015 at 10:31 AM, Amit Kapila wrote: > > > Could you perhaps try to create a testcase where xids are accessed that > > > are so far apart on average that they're unlikely to be

Re: [HACKERS] Moving SS_finalize_plan processing to the end of planning

On Thu, Sep 10, 2015 at 9:49 PM, Tom Lane wrote: > Robert Haas writes: >> Do you expect to do more work on the upper planner path-ification stuff soon? > > Yeah, I do actually have some work in progress. Not sure how soon I'll be > ready to show it ---

[HACKERS][PROPOSAL] Covering + unique indexes.

Hi, hackers! Use case: Index-only scans is a wonderful feature that allows to speed up select queries of indexed columns. Therefore some users want to create multicolumn indexes on columns which are queried often. But if there's unique constraint on some column, they have to maintain another

Re: [HACKERS] Moving SS_finalize_plan processing to the end of planning

Robert Haas writes: > On Thu, Sep 10, 2015 at 9:49 PM, Tom Lane wrote: >> Robert Haas writes: >>> Do you expect to do more work on the upper planner path-ification stuff >>> soon? >> Yeah, I do actually have some work in

Re: [HACKERS] 9.3.9 and pg_multixact corruption

Re: Bernd Helmle 2015-09-10 <7E3C7F8D210AC9A423E96F3A@eje.local> > 2015-09-08 11:40:59 CEST [27047] DETAIL: Could not seek in file > "pg_multixact/members/5FC4" to offset 4294950912: Invalid argument. > 2015-09-08 11:40:59 CEST [27047] CONTEXT: xlog redo create mxid 1068235595 > offset

[HACKERS] Did we forget to unpin buf in function "revmap_physical_extend" ?

In function "revmap_physical_extend", should we add "ReleaseBuffer(buf);" between line 438 and 439 ? 422 else 423 { 424 if (needLock) 425 LockRelationForExtension(irel, ExclusiveLock); 426 427 buf = ReadBuffer(irel, P_NEW); 428 if

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

On Wed, Sep 9, 2015 at 4:30 PM, Kevin Grittner wrote: > Robert Haas wrote: > >> I think the problem we should be trying to solve is: Given a set >> of server IPs, connect to one that is up. >> >> I believe this comes up in several different scenarios. >>

Re: [HACKERS] RLS open items are vague and unactionable

* Dean Rasheed (dean.a.rash...@gmail.com) wrote: > I think blind updates are a pretty niche case, and I think that it > wasn't the intention to support them, but more of an unintentional > side effect of the implementation. That said, there are > just-about-plausible use-cases where they might be

Re: [HACKERS] RLS open items are vague and unactionable

Dean Rasheed writes: > Yeah, we had a similar discussion regarding UPDATE USING policies and > ON CONFLICT UPDATE clauses. I think the argument against filtering is > that the rows returned would then be misleading about what was > actually updated. It seems to me that

Re: [HACKERS] RLS open items are vague and unactionable

On 11 September 2015 at 15:20, Stephen Frost wrote: > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >> I think blind updates are a pretty niche case, and I think that it >> wasn't the intention to support them, but more of an unintentional >> side effect of the

Re: [HACKERS] RLS open items are vague and unactionable

On 09/11/2015 04:33 AM, Stephen Frost wrote: > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >> I will happily work up a rebased version of the patch, but only if I >> get a serious commitment from a committer to review it. Otherwise, >> I'll let it drop. > > There's no question about getting

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Thu, Sep 3, 2015 at 5:11 PM, Andres Freund wrote: > > On 2015-09-01 10:19:19 +0530, Amit Kapila wrote: > > pgbench setup > > > > scale factor - 300 > > Data is on magnetic disk and WAL on ssd. > > pgbench -M prepared tpc-b > > > > HEAD - commit

Re: [HACKERS] Moving SS_finalize_plan processing to the end of planning

On Fri, Sep 11, 2015 at 9:14 AM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Sep 10, 2015 at 9:49 PM, Tom Lane wrote: >>> Robert Haas writes: Do you expect to do more work on the upper planner

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello, Please find attached updated VACUUM progress checker patch. Following have been accomplished in the patch 1. Accounts for index pages count while calculating total progress of VACUUM. 2. Common location for storing progress parameters for any command. Idea is every command which needs

Re: [HACKERS] Latent cache flush hazard in RelationInitIndexAccessInfo

On Wed, Sep 9, 2015 at 3:00 PM, Tom Lane wrote: > Some stuff Salesforce has been doing turned up the fact that > RelationInitIndexAccessInfo is not safe against a relcache flush on > its target index. Specifically, the failure goes like this: > > * RelationInitIndexAccessInfo

Re: [HACKERS] Double linking MemoryContext children

On 09/11/2015 09:58 AM, Tom Lane wrote: Jan Wieck writes: On 09/11/2015 09:38 AM, Tom Lane wrote: Seems less invasive to fix SPI to delete in the opposite order? That would assume that there are no other code paths that destroy memory contexts out of LIFO order. Given

Re: [HACKERS] Do Layered Views/Relations Preserve Sort Order ?

On Wed, Sep 9, 2015 at 7:53 PM, Charles Sheridan wrote: > When there are several views defined on top of each other, are SELECTs on > views that do not specify a SORT order guaranteed to preserve the cumulative > sort order of the lower-level views ? > > Is the answer true for

Re: [HACKERS] RLS open items are vague and unactionable

On Fri, Sep 11, 2015 at 10:49 AM, Tom Lane wrote: > Dean Rasheed writes: >> Yeah, we had a similar discussion regarding UPDATE USING policies and >> ON CONFLICT UPDATE clauses. I think the argument against filtering is >> that the rows returned would

Re: [HACKERS] RLS open items are vague and unactionable

On Fri, Sep 11, 2015 at 9:48 AM, Stephen Frost wrote: > The only reason to avoid providing that flexibility is the concern that > it might be misunderstood and users might misconfigure their system. > Removing the flexibility to have per-command visibility policies and >

Re: [HACKERS] 9.3.9 and pg_multixact corruption

On 2015-09-11 14:25:39 +0200, Christoph Berg wrote: > A few more words here: the archive recovery was a pitr to 00:45, so > well before the problem, and the cluster was initially working well, > but crashed shortly after with the same mxid 1068235595 message. The > crash was triggered from a

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Fri, Sep 11, 2015 at 10:31 AM, Amit Kapila wrote: > > Could you perhaps try to create a testcase where xids are accessed that > > are so far apart on average that they're unlikely to be in memory? And > > then test that across a number of client counts? > > > > Now

Re: [HACKERS] Partitioned checkpointing

On 09/11/2015 03:56 PM, Simon Riggs wrote: The idea to do a partial pass through shared buffers and only write a fraction of dirty buffers, then fsync them is a good one. The key point is that we spread out the fsyncs across the whole checkpoint period. I doubt that's really what we want

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Thu, Sep 10, 2015 at 11:36 PM, Etsuro Fujita wrote: > I've proposed the following API changes: > > * I modified create_foreignscan_path, which is called from > postgresGetForeignJoinPaths/postgresGetForeignPaths, so that a path, > subpath, is passed as the eighth

Re: [HACKERS] DBT-3 with SF=20 got failed

On Wed, Sep 9, 2015 at 11:54 AM, Tomas Vondra wrote: > Secondly, we limit the number of buckets to INT_MAX, so about 16GB (because > buckets are just pointers). No matter how awful estimate you get (or how > insanely high you set work_mem) you can't exceed this. OK,

Re: [HACKERS] DBT-3 with SF=20 got failed

On 09/11/2015 06:55 PM, Robert Haas wrote: On Wed, Sep 9, 2015 at 11:54 AM, Tomas Vondra wrote: Secondly, we limit the number of buckets to INT_MAX, so about 16GB (because buckets are just pointers). No matter how awful estimate you get (or how insanely high you