Hi
2015-09-11 17:59 GMT+02:00 Teodor Sigaev :
> 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 tabl
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 Check
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 checkpoin
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.
>
> I guess I'm being
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 in memory? And
> > > then test that across a num
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 1
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
> > of OIDs in unused OID lis
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 touch
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.
--
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
> > S
>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
--
Se
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.
I agree with Tom and Robe
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
>> > transactions should behave?
>>
>> I have to admit
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
> 1452 *Creates a path cor
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
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 flushed. This improve
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, P_N
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 generated from (or using) lwlocknames.c
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 it differently. I think the
bug
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 UPDATE and SELECT policies,
>>> ie if there's RETURNING then you ca
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 to estimate the s
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 passing a value to palloc that is
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 set work_mem) you can't exceed
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
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 with
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 update a row you could not
>> have selected. Note
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, so this is an interesting poin
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 fro
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: h
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
>> remaining concerns about moving the h
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 PlanState tree at least
> currently.
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 then be misleading about what was
>> actually upd
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 private field is
> the expre
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 argument of the function. subpa
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 afte
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,
nothin
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 of
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.
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 digits
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 and don't see any speedup, so
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
> Pin
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 location for storing progr
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 12 bytes, counting a
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 postgre
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 to
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 about the test, create a tabl
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 delete
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
> instead force a single vis
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 then be misleading about what was
>> actually
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 any arbitrarily larg
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 loads up relation->r
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 t
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 that we've not seen
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 path-ification stuff
soon?
>
>>> Yeah, I do actually have some work in progress. Not
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 i
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 it would be a horribly bad
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 implementation. That said, there
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 0e141c0f
> > Patch-1 - in
* 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 c
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 examples
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 allow blind updates and del
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 problem reported in the
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 wal-log entry, pacing, fsyn
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 [DBNAME]
NUM_STMTS de
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 the question regarding
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. The code block ex
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
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
>> postgres
>> ERROR: invalid mem
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 progress. Not sure how soon I'll be
>> ready to show it --- there's a lo
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 u
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.
>>
>> Example #1: [single server; changing IP
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 --- there's a lot of code to break and reassemb
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 (BufferGetBlock
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 214748
>
> 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 user
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'
> context which I posted a p
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 patch doesn't fix any b
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 scen
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
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 o
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 t
...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: 201306121
Database system identi
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 would
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 Paquier writes:
As promised, here's a V2 to address your issues with comments
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 make the code simpler and m
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.
Do you have an idea of what
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, ExecForeignScan, ExecEndForeig
87 matches
Mail list logo
