As an extra data point, if you try this in Python (psycopg2) you get an
exception:
psycopg2.ProgrammingError: autocommit cannot be used inside a transaction
I think this exception is a legitimate response. If the user switches on
autocommit mode inside a transaction, it was most likely not on pu
On Fri, Aug 5, 2016 at 11:27 AM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> If concurrent deletion (marking half-dead, specifically) can't
> happen, P_ISDELETED() won't be seen in the loop but we may
> consider it as a skippable condition to continue VACUUM. But
> still I think we shouldn't release the
2016-08-06 7:29 GMT+02:00 Amit Kapila :
> On Thu, Aug 4, 2016 at 7:46 PM, Pavel Stehule
> wrote:
>
> > 2016-08-04 15:37 GMT+02:00 Amit Kapila :
> >>
> >> > I dislike automatic commit or rollback here.
> >> >
> >>
> >> What problem you see with it, if we do so and may be mention the same
> >> in d
On Thu, Aug 4, 2016 at 7:46 PM, Pavel Stehule wrote:
> 2016-08-04 15:37 GMT+02:00 Amit Kapila :
>>
>> > I dislike automatic commit or rollback here.
>> >
>>
>> What problem you see with it, if we do so and may be mention the same
>> in docs as well. Anyway, I think we should make the behaviour o
On Sat, Aug 6, 2016 at 8:34 AM, Bruce Momjian wrote:
> On Fri, Aug 5, 2016 at 09:40:35PM -0400, Bruce Momjian wrote:
> > So to summarize again:
> >
> > o chains start out as HOT
> > o they become WARM when some indexes change and others don't
> > o for multiple index changes, we have to check
On Thu, Aug 4, 2016 at 7:24 PM, Mithun Cy
wrote:
> I am attaching the patch to improve some coverage of hash index code [1].
> I have added some basic tests, which mainly covers overflow pages. It took
> 2 sec extra time in my machine in parallel schedule.
>
>
>
>
> Hit Total Coverage
> old tests
On Fri, Aug 5, 2016 at 09:40:35PM -0400, Bruce Momjian wrote:
> So to summarize again:
>
> o chains start out as HOT
> o they become WARM when some indexes change and others don't
> o for multiple index changes, we have to check all indexes
>for key/ctid matches
> o for single index chang
On 8/5/16 12:14 AM, Michael Paquier wrote:
> In do_stop, this patches makes the wait happen for a maximum of
> wait_seconds * 2, once when getting the control file information, and
> once when waiting for the server to shut down.
That's not how I read it. get_controlfile() will decrease the
wait_
On Fri, Aug 5, 2016 at 09:02:39PM -0400, Bruce Momjian wrote:
> Yes, it seems we either find the entry fast and avoid the index
> addition, or don't find it quickly and use a non-HOT, non-WARM update.
> The problem is that you have to do this for multiple indexes, and if you
> quickly find you nee
On Fri, Aug 5, 2016 at 09:21:49PM -0300, Claudio Freire wrote:
> On Fri, Aug 5, 2016 at 9:07 PM, Bruce Momjian wrote:
> > On Fri, Aug 5, 2016 at 07:51:05PM -0300, Claudio Freire wrote:
> >> > This does create more HOT chains where the root ctid cannot be removed,
> >> > but it does avoid the ind
On Fri, Aug 5, 2016 at 9:21 PM, Claudio Freire wrote:
> On Fri, Aug 5, 2016 at 9:07 PM, Bruce Momjian wrote:
>> On Fri, Aug 5, 2016 at 07:51:05PM -0300, Claudio Freire wrote:
>>> > This does create more HOT chains where the root ctid cannot be removed,
>>> > but it does avoid the index key/ctid
On Fri, Aug 5, 2016 at 9:07 PM, Bruce Momjian wrote:
> On Fri, Aug 5, 2016 at 07:51:05PM -0300, Claudio Freire wrote:
>> > This does create more HOT chains where the root ctid cannot be removed,
>> > but it does avoid the index key/ctid check because any entry in the HOT
>> > chain has identical
>
> > I really don't get what's problematic with posting a message on a mailing
> > list about a potential performance issue, to try to get people's
> reactions,
> > without diving into profiling right away. I'm not a PostgreSQL developer,
> > have other urgent things to do and don't even spend mos
On Fri, Aug 5, 2016 at 07:51:05PM -0300, Claudio Freire wrote:
> > This does create more HOT chains where the root ctid cannot be removed,
> > but it does avoid the index key/ctid check because any entry in the HOT
> > chain has identical keys. What this would not handle is when an entire
> > HOT
Peter Eisentraut writes:
> One hiccup I found is that server_version_num is not sent to clients.
> Instead, libpq assembles the numeric version number itself from the
> string version, and it will fail if it sees only one number (e.g.,
> 10devel). It will then set the version number to 0 for "unk
On Fri, Aug 5, 2016 at 4:26 PM, Bruce Momjian wrote:
> On Fri, Aug 5, 2016 at 11:30:26PM +0530, Pavan Deolasee wrote:
>> On Fri, Aug 5, 2016 at 11:26 PM, Bruce Momjian wrote:
>>
>> On Fri, Aug 5, 2016 at 02:43:37PM -0300, Claudio Freire wrote:
>> > But doing the WARM chain backtracking
On 8/1/16 1:08 AM, Haribabu Kommi wrote:
There are some utilities and functions that are available to calculate the
current system load, based on the available resources and system load,
the module can allow the number of parallel workers that can start. In my
observation, adding this calculation
On Sat, Aug 6, 2016 at 2:38 AM, Tomas Vondra
wrote:
> On 08/05/2016 06:24 AM, Michael Paquier wrote:
>>
>> On Wed, Aug 3, 2016 at 10:58 AM, Tomas Vondra
>> wrote:
>>>
>>> Attached is v19 of the "multivariate stats" patch series - essentially
>>> v18
>>> rebased on top of current master. Aside fro
On Fri, Aug 5, 2016 at 03:26:15PM -0400, Bruce Momjian wrote:
> > I just don't know how would you do that without delaying/not-doing HOT chain
> > prune. As soon as root and intermediate HOT tuples are gone, all
> > information is
> > lost. You may delay that, but that will defeat the whole purpo
Andrew Gierth writes:
> Objection withdrawn.
OK, thanks. What shall we do about Andreas' request to back-patch this?
I'm personally willing to do it, but there is the old bugaboo of "maybe
it will destabilize a plan that someone is happy with".
regards, tom lane
--
Se
On 2016-08-05 16:44:20 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-08-05 16:35:02 -0400, Tom Lane wrote:
> >> In particular, it seems to me that rather than implement just this,
> >> we really ought to provide an API that lets FDWs actually implement
> >> TRUNCATE if they feel like
On Fri, Aug 5, 2016 at 9:06 AM, Robert Haas wrote:
> To some extent, sure, absolutely. But it's our job as developers to
> try to foresee and minimize those cases. When Noah was at
> EnterpriseDB a few years ago and we were talking about parallel
> internal sort, Noah started by doing a survey o
Andres Freund writes:
> On 2016-08-05 16:35:02 -0400, Tom Lane wrote:
>> In particular, it seems to me that rather than implement just this,
>> we really ought to provide an API that lets FDWs actually implement
>> TRUNCATE if they feel like it. Having the trigger and not TRUNCATE
>> capability i
On 2016-08-05 16:35:02 -0400, Tom Lane wrote:
> In particular, it seems to me that rather than implement just this,
> we really ought to provide an API that lets FDWs actually implement
> TRUNCATE if they feel like it. Having the trigger and not TRUNCATE
> capability itself just screams "half bake
Andres Freund writes:
> On 2016-08-05 14:05:02 -0400, Robert Haas wrote:
>> I agree, but I still think it's weird if foreign tables support
>> TRUNCATE itself not but triggers on TRUNCATE.
> You mean the other way round? To me this seems very comparable to
> INSTEAD triggers, but ...
While I ha
Basically,
diff --git a/src/backend/parser/parse_param.c
b/src/backend/parser/parse_param.c
index b402843..97064fc 100644
--- a/src/backend/parser/parse_param.c
+++ b/src/backend/parser/parse_param.c
@@ -108,6 +108,9 @@ fixed_paramref_hook(ParseState *pstate, ParamRef *pref)
ereport(ERROR,
(er
On Fri, Aug 5, 2016 at 12:17 PM, Tom Lane wrote:
> Jeff Janes writes:
>> I have it PGC_SUSET because it does send some tiny amount of
>> information about the blocking process (the PID) to the blocked
>> process. That is probably too paranoid, because the PID can be seen
>> by anyone in the pg_l
On Fri, Aug 5, 2016 at 11:30:26PM +0530, Pavan Deolasee wrote:
> On Fri, Aug 5, 2016 at 11:26 PM, Bruce Momjian wrote:
>
> On Fri, Aug 5, 2016 at 02:43:37PM -0300, Claudio Freire wrote:
> > But doing the WARM chain backtracking and checking for previous
> > versions with appropriate
Jeff Janes writes:
> I have it PGC_SUSET because it does send some tiny amount of
> information about the blocking process (the PID) to the blocked
> process. That is probably too paranoid, because the PID can be seen
> by anyone in the pg_locks table anyway.
Why not just leave out the PID? I t
On 05/08/2016 19:00, Jeff Janes wrote:
> One time too many, I ran some minor change using psql on a production
> server and was wondering why it was taking so much longer than it did
> on the test server. Only to discover, after messing around with
> opening new windows and running queries against
On Fri, Aug 5, 2016 at 02:07:18PM -0400, Robert Haas wrote:
> On Fri, Aug 5, 2016 at 11:06 AM, Bruce Momjian wrote:
> > On Fri, Aug 5, 2016 at 10:57:35AM -0400, Peter Eisentraut wrote:
> >> On 8/2/16 12:51 PM, Bruce Momjian wrote:
> >> > Yes, that's a strong argument for using a space. I have a
Thomas Munro writes:
> The assertion in tsvector_delete_by_indices fails because its counting
> algorithm doesn't expect indices_to_delete to contain multiple
> references to the same index. Maybe that could be fixed by
> uniquifying in tsvector_delete_arr before calling it, but since
> tsvector_
On Tue, Aug 2, 2016 at 2:59 AM, Fujii Masao wrote:
> On Tue, Aug 2, 2016 at 2:48 AM, Andres Freund wrote:
>> Hi Fujii,
>>
>> On 2016-07-28 16:44:37 +0900, Fujii Masao wrote:
>>> On Sat, Jul 2, 2016 at 7:01 AM, Tom Lane wrote:
>>> > Andres Freund writes:
>>> >> On 2016-06-30 10:14:04 -0400, Tom
On 2016-08-05 14:05:02 -0400, Robert Haas wrote:
> On Fri, Aug 5, 2016 at 2:04 PM, Andres Freund wrote:
> > On 2016-08-05 13:32:18 -0400, Robert Haas wrote:
> >> I think if we're going to add support utility commands on foreign
> >> tables, we ought to think about all of the different utility comm
On Fri, Aug 5, 2016 at 11:06 AM, Bruce Momjian wrote:
> On Fri, Aug 5, 2016 at 10:57:35AM -0400, Peter Eisentraut wrote:
>> On 8/2/16 12:51 PM, Bruce Momjian wrote:
>> > Yes, that's a strong argument for using a space. I have adjusted the
>> > patch to use spaces in all reasonable places. Patch
On Fri, Aug 5, 2016 at 2:04 PM, Andres Freund wrote:
> On 2016-08-05 13:32:18 -0400, Robert Haas wrote:
>> I think if we're going to add support utility commands on foreign
>> tables, we ought to think about all of the different utility commands
>> that someone might want and what exactly we want
On 2016-08-05 13:32:18 -0400, Robert Haas wrote:
> I think if we're going to add support utility commands on foreign
> tables, we ought to think about all of the different utility commands
> that someone might want and what exactly we want the behavior to be.
> For example, consider CLUSTER or CRE
On Fri, Aug 5, 2016 at 11:26 PM, Bruce Momjian wrote:
> On Fri, Aug 5, 2016 at 02:43:37PM -0300, Claudio Freire wrote:
> > But doing the WARM chain backtracking and checking for previous
> > versions with appropriate keys should be enough to support this use
> > case too, it just needs to be wel
On Fri, Aug 5, 2016 at 02:43:37PM -0300, Claudio Freire wrote:
> But doing the WARM chain backtracking and checking for previous
> versions with appropriate keys should be enough to support this use
> case too, it just needs to be well optimized to avoid seriously
> impacting performance on the av
Anastasia Lubennikova wrote:
> Working on page compression and some other issues related to
> access methods, I found out that the code related to heap
> looks too complicated. Much more complicated, than it should be.
> Since I anyway got into this area, I want to suggest a set of improvements.
H
On Fri, Aug 5, 2016 at 2:26 PM, Pavan Deolasee wrote:
> On Fri, Aug 5, 2016 at 8:55 PM, Claudio Freire
> wrote:
>>
>> On Fri, Aug 5, 2016 at 1:27 AM, Pavan Deolasee
>> wrote:
>> >
>> >
>> > I don't see why it is hard. Trying to find the index entry for the old
>> > update row seems odd, and upd
> "Tom" == Tom Lane writes:
Tom> Also, the way that the value is calculated in the
Tom> samples-not-all-distinct case corresponds to the way I have it in
Tom> the patch.
Ahh, gotcha. You're referring to this:
/*
* If we estimated the number of distinct values at more th
Robert Haas writes:
> Action within 72 hours now seems inadequate; we are scheduled to wrap
> rc1 on Monday. We need someone to either fix these bugs very very
> soon, or decide to ship beta4 instead of rc1 (uggh), or decide it's OK
> to ship rc1 with these known defects, or postpone the planned
On Fri, Aug 5, 2016 at 10:39 AM, Andres Freund wrote:
> On 2016-08-05 10:33:49 -0400, Tom Lane wrote:
>> Murat Tuncer writes:
>> > I recently hit a road blocker when I tried to create a truncate trigger on
>> > a foreign table. trigger.c::CreateTrigger() function has explicit check to
>> > block
On 08/05/2016 06:24 AM, Michael Paquier wrote:
On Wed, Aug 3, 2016 at 10:58 AM, Tomas Vondra
wrote:
Attached is v19 of the "multivariate stats" patch series - essentially v18
rebased on top of current master. Aside from a few bug fixes, the main
improvement is addition of SGML docs demonstratin
On Fri, Aug 5, 2016 at 10:39 AM, Kenneth Marshall wrote:
> I have been following the recent discussions on increasing the
> size of the hash function used in Postgres and the work to
> provide WAL and performance improvements for hash indexes.
> I know it was mentioned when we moved to the new has
On Fri, Aug 5, 2016 at 8:55 PM, Claudio Freire
wrote:
> On Fri, Aug 5, 2016 at 1:27 AM, Pavan Deolasee
> wrote:
> >
> >
> > I don't see why it is hard. Trying to find the index entry for the old
> > update row seems odd, and updating an index row seems odd, but skipping
> > an index addition fo
Peter Eisentraut writes:
> The input function of the money type has no overflow checks:
Ugh.
> (Is checking for < 0 a valid overflow check?
No, I don't think it's sufficient after a multiplication by 10. That
would be enough to shift some bits clear out of the word, but there's
no certainty th
On 5 August 2016 at 16:22, Andres Freund wrote:
> On 2016-08-05 17:00:13 +0200, Petr Jelinek wrote:
>> as promised here is WIP version of logical replication patch.
>
> Yay!
Yay2
> I'm about to head out for a week of, desperately needed, holidays, but
> after that I plan to spend a fair amount o
One time too many, I ran some minor change using psql on a production
server and was wondering why it was taking so much longer than it did
on the test server. Only to discover, after messing around with
opening new windows and running queries against pg_stat_activity and
pg_locks and so on, that
On Thu, Aug 4, 2016 at 8:14 AM, Aleksander Alekseev
wrote:
> Thanks everyone for your remarks and comments!
>
> Here is an improved version of a patch.
>
> Main changes:
> * Patch passes `make installcheck`
> * Code is fully commented, also no more TODO's
>
> I wish I sent this version of a patch
On Fri, Aug 5, 2016 at 3:25 AM, Tsunakawa, Takayuki
wrote:
>> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> Yeah, I think I agree. It would be bad to disable it by default on Unix,
>> because ps(1) is a very standard tool there, but the same argument doesn't
>> hold for Windows.
>
> It seems that
30.07.2016 14:00, Andrew Borodin:
Here is BRIN-compatible version of patch. Now function
PageIndexTupleOverwrite consumes tuple size as a parameter, this
behavior is coherent with PageAddItem.
Also, i had to remove asserstion that item has a storage in the loop
that adjusts line pointers. It woul
On 8/5/16 11:58 AM, David Fetter wrote:
> For what it's worth, I tend to put the function body last. That's
> just my taste, though. Would it be hard to keep the ability to
> permute the stuff after
>
> CREATE FUNCTION (args)
> RETURNS [SETOF] type
>
> as we have it now?
I don't think
On Thu, Aug 4, 2016 at 12:14 AM, Noah Misch wrote:
> On Wed, Aug 03, 2016 at 05:52:44PM -0400, Tom Lane wrote:
>> I wrote:
>> > I'm thinking there are two distinct bugs here.
>>
>> Actually, make that three bugs. I was so focused on the crashing
>> that I failed to notice that ts_delete wasn't pr
On Wed, Aug 3, 2016 at 5:13 PM, Peter Geoghegan wrote:
> On Wed, Aug 3, 2016 at 11:42 AM, Robert Haas wrote:
>> I'm not going to say it's bad to be able to do things 2-2.5x faster,
>> but linear scalability this ain't - particularly because your 2.58x
>> faster case is using up to 7 or 8 times as
The input function of the money type has no overflow checks:
=> select '12345678901234567890'::money;
money
-
-$13,639,628,150,831,692.72
(1 row)
The tests in the regression test file money.sql are bogus because they
only test the overflow checks of the bi
On Fri, Aug 5, 2016 at 11:05 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Aug 4, 2016 at 10:58 PM, Robert Haas wrote:
>>> What is the reason? We refuse to separate frontend and backend
>>> headers in any sort of principled way?
>
>> That was poorly phrased. I'll try again: I can't see
On Fri, Aug 05, 2016 at 10:14:21AM -0400, Peter Eisentraut wrote:
> On 7/3/16 11:41 AM, Tom Lane wrote:
> > I can see the reasoning for
> > allowing COMMENT in a table column definition, but the argument for
> > allowing it in simpler CREATEs seems tissue-thin:
> >
> > CREATE FUNCTION foo(int)
On Fri, Aug 5, 2016 at 10:11 AM, Tom Lane wrote:
> Robert Haas writes:
>> I think it would be an interesting project for someone to try to
>> figure out how to make 'make check-extended-query-protocol' or similar
>> work.
>
> Seems like it would not be that hard to put some kind of option in psql
On Fri, Aug 5, 2016 at 12:25:39PM -0300, Claudio Freire wrote:
> > 2. The existence of index pointers to intermediate tuples will lead to index
> > bloat. This is the same problem that we found in Simon's original proposal
> > (discussed internally). None of the intermediate line pointers can be
>
On Fri, Aug 5, 2016 at 1:27 AM, Pavan Deolasee wrote:
>
>
> On Fri, Aug 5, 2016 at 8:23 AM, Claudio Freire
> wrote:
>>
>> On Thu, Aug 4, 2016 at 11:15 PM, Bruce Momjian wrote:
>>
>> >
>> > OK, that's a lot of text, and I am confused. Please tell me the
>> > advantage of having an index point to
On 8/4/16 2:21 PM, Tom Lane wrote:
> Forgot to mention: seems like you should have added a location
> argument to makeDefElem.
I was hesitating to do that lest it break extensions or something, but I
guess we break bigger things than that all the time. I'll change it.
--
Peter Eisentraut
On 8/4/16 2:08 PM, Tom Lane wrote:
> +1 on the general idea, but I wonder if it's a problem that you replaced
> an O(N) check with an O(N^2) check. I don't think there are any commands
> that would be likely to have so many options that this would become a
> serious issue, but ...
I'll run some t
On 8/4/16 9:42 AM, Tom Lane wrote:
> I'm inclined to think that we should reset the message locale
> to C as soon as we've forked away from the postmaster, and leave it
> that way until we've absorbed settings from the startup packet.
> Sending messages of this sort in English isn't great, but it's
On 8/4/16 2:45 AM, Victor Wagner wrote:
> 4. At the session startup try to reinitializie LC_MESSAGES locale
> category with the combination
> of the server (or better client-send) language and region and
> client-supplied encoding, and if this failed, use untranslated error
> message. Obvoisly, att
On 2016-08-05 17:00:13 +0200, Petr Jelinek wrote:
> as promised here is WIP version of logical replication patch.
Yay!
I'm about to head out for a week of, desperately needed, holidays, but
after that I plan to spend a fair amount of time helping to review
etc. this.
--
Sent via pgsql-hackers
On Fri, Aug 5, 2016 at 10:57:35AM -0400, Peter Eisentraut wrote:
> On 8/2/16 12:51 PM, Bruce Momjian wrote:
> > Yes, that's a strong argument for using a space. I have adjusted the
> > patch to use spaces in all reasonable places. Patch attached, which I
> > have gzipped because it was 133 KB.
Robert Haas writes:
> On Thu, Aug 4, 2016 at 10:58 PM, Robert Haas wrote:
>> What is the reason? We refuse to separate frontend and backend
>> headers in any sort of principled way?
> That was poorly phrased. I'll try again: I can't see any reason for
> using a macro here except that it allows
On 8/2/16 12:51 PM, Bruce Momjian wrote:
> Yes, that's a strong argument for using a space. I have adjusted the
> patch to use spaces in all reasonable places. Patch attached, which I
> have gzipped because it was 133 KB. (Ah, see what I did there?) :-)
>
> I am thinking of leaving the 9.6 doc
Hello Developers,
I have been following the recent discussions on increasing the
size of the hash function used in Postgres and the work to
provide WAL and performance improvements for hash indexes.
I know it was mentioned when we moved to the new hashing
functions, but the existing functions do
On 2016-08-05 10:33:49 -0400, Tom Lane wrote:
> Murat Tuncer writes:
> > I recently hit a road blocker when I tried to create a truncate trigger on
> > a foreign table. trigger.c::CreateTrigger() function has explicit check to
> > block truncate trigger on foreign tables.
>
> That's good, because
Murat Tuncer writes:
> I recently hit a road blocker when I tried to create a truncate trigger on
> a foreign table. trigger.c::CreateTrigger() function has explicit check to
> block truncate trigger on foreign tables.
That's good, because we don't implement TRUNCATE on foreign tables: there
is n
Andrew Gierth writes:
> Hm. I am wrong about this, since it's the fact that consumers are taking
> stanullfrac into account that makes the value wrong in the first place.
Also, the way that the value is calculated in the samples-not-all-distinct
case corresponds to the way I have it in the patch.
On 7/3/16 11:41 AM, Tom Lane wrote:
> I can see the reasoning for
> allowing COMMENT in a table column definition, but the argument for
> allowing it in simpler CREATEs seems tissue-thin:
>
> CREATE FUNCTION foo(int) RETURNS ... ;
> COMMENT ON FUNCTION foo(int) IS 'blah';
>
> vs
>
>
Robert Haas writes:
> I think it would be an interesting project for someone to try to
> figure out how to make 'make check-extended-query-protocol' or similar
> work.
Seems like it would not be that hard to put some kind of option in psql
to issue queries with PQexecParams not plain PQexec. How
On Thu, Aug 4, 2016 at 3:24 AM, Andres Freund wrote:
> Hi,
>
> On 2016-08-02 10:55:18 -0400, Noah Misch wrote:
>> [Action required within 72 hours. This is a generic notification.]
>>
>> The above-described topic is currently a PostgreSQL 9.6 open item. Andres,
>> since you committed the patch b
On Tue, Aug 2, 2016 at 2:00 PM, Shay Rojansky wrote:
>> Shay, why don't you use a profiler? Seriously.
>> I'm afraid "iterate the per-message loop in PostgresMain five times not
>> once" /"just discussing what may or may not be a problem..." is just
>> hand-waving.
>>
>> Come on, it is not that h
On Fri, Aug 5, 2016 at 01:12:39PM +0200, David Rowley wrote:
> On 5 August 2016 at 12:25, Tsunakawa, Takayuki
> wrote:
> > It seems that we could reach a consensus. The patch is attached. I'll add
> > this to the next CommitFest.
>
>
> + The default is off on Windows
> + beca
On Wed, Aug 3, 2016 at 7:35 PM, Bruce Momjian wrote:
> On Wed, Aug 3, 2016 at 10:02:39AM -0400, Tom Lane wrote:
>> Bruce Momjian writes:
>> > On Sun, Jul 31, 2016 at 05:57:12PM -0400, Tom Lane wrote:
>> >> In hindsight it seems clear that what a lot of apps want out of extended
>> >> protocol is
On Fri, Aug 5, 2016 at 09:57:19AM +0530, Pavan Deolasee wrote:
> Hmm. That seems like a real problem. The only way to address that is to ensure
> that for a given WARM chain and given index key, there must exists only a
> single index entry. There can and will be multiple entries if the index key
05.08.2016 16:30, Kevin Grittner:
On Fri, Aug 5, 2016 at 2:54 AM, Anastasia Lubennikova
wrote:
They can be logically separated into three categories:
"primary storage" - r, S, t, v. They store data and visibility information.
The only implementation is heapam.c
"secondary index" - i. They stor
On Thu, Aug 4, 2016 at 3:36 AM, Tom Lane wrote:
> Jeff Janes writes:
>> On Fri, Jul 22, 2016 at 3:02 AM, Mithun Cy
>> wrote:
>>> I have created a patch to cache the meta page of Hash index in
>>> backend-private memory. This is to save reading the meta page buffer every
>>> time when we want to
On Fri, Aug 5, 2016 at 2:54 AM, Anastasia Lubennikova
wrote:
> They can be logically separated into three categories:
> "primary storage" - r, S, t, v. They store data and visibility information.
> The only implementation is heapam.c
> "secondary index" - i. They store some data and pointers to p
On Tue, Aug 2, 2016 at 10:33 PM, Tatsuo Ishii wrote:
> In my understanding, we don't have any regression test for protocol
> level prepared query (we do have SQL level prepared query tests,
> though). Shouldn't we add those tests to the regression test suites?
A few years ago, EDB had a bug that
On Tue, Jul 26, 2016 at 11:20 PM, Etsuro Fujita
wrote:
> I noticed that currently the core doesn't show any information on the target
> relations involved in a foreign/custom join in EXPLAIN, by itself.
I think that's a feature, not a bug.
> postgres_fdw shows the target relations in the Relatio
>
> >
> > Consider lists ('e', 'i', 'f'), ('h', 'd','m') and ('l', 'b', 'a') for a
> > list partitioned tables. I am suggesting that we arrange them as
> > ('a','b','l'), ('d', 'h', 'm') and ('e', 'f', 'i'). If the given row
> (either
> > for comparison or for inserting) has value 'c', we will sear
On Thu, 04 Aug 2016 14:25:52 -0400
Tom Lane wrote:
> Victor Wagner writes:
> > Really, if this response is sent after backend has been forked,
> > problem probably can be easily fixed better way - StartupMessage
> > contain information about desired client encoding, so this
> > information just
On Fri, Aug 5, 2016 at 8:10 AM, Ashutosh Bapat
wrote:
> On Fri, Aug 5, 2016 at 5:21 PM, Robert Haas wrote:
>> On Fri, Aug 5, 2016 at 6:53 AM, Ashutosh Bapat
>> wrote:
>> > The lists for list partitioned tables are stored as they are specified
>> > by
>> > the user. While searching for a partitio
On Fri, Aug 5, 2016 at 5:21 PM, Robert Haas wrote:
> On Fri, Aug 5, 2016 at 6:53 AM, Ashutosh Bapat
> wrote:
> > The lists for list partitioned tables are stored as they are specified by
> > the user. While searching for a partition to route tuple to, we compare
> it
> > with every list value of
On Fri, Aug 5, 2016 at 6:53 AM, Ashutosh Bapat
wrote:
> The lists for list partitioned tables are stored as they are specified by
> the user. While searching for a partition to route tuple to, we compare it
> with every list value of every partition. We might do something better
> similar to what'
On Thu, Aug 4, 2016 at 8:02 PM, Mithun Cy wrote:
> I did some basic testing of same. In that I found one issue with cursor.
>
Thanks for the testing. The reason for failure was that the patch
didn't take into account the fact that for scrolling cursors, scan can
reacquire the lock and pin on buc
On 5 August 2016 at 12:25, Tsunakawa, Takayuki
wrote:
> It seems that we could reach a consensus. The patch is attached. I'll add
> this to the next CommitFest.
+ The default is off on Windows
+ because the overhead is significant, and on on other platforms.
"than on other pl
The lists for list partitioned tables are stored as they are specified by
the user. While searching for a partition to route tuple to, we compare it
with every list value of every partition. We might do something better
similar to what's been done to range partitions. The list of values for a
given
> "Andrew" == Andrew Gierth writes:
> "Tom" == Tom Lane writes:
Tom> What I did in the patch is to scale the formerly fixed "-1.0"
Tom> stadistinct estimate to discount the fraction of nulls we found.
Andrew> This seems quite dubious to me. stadistinct representing only
Andrew> the
On 5 August 2016 at 04:40, Etsuro Fujita wrote:
> On 2016/08/02 23:54, Simon Riggs wrote:
>>
>> https://wiki.postgresql.org/wiki/PostgreSQL10_Roadmap
>
>
> Thank you for creating the wiki page!
>
> I added a link to the NTT roadmap page on the links page. We hope that we
> can collaborate on the
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Yeah, I think I agree. It would be bad to disable it by default on Unix,
> because ps(1) is a very standard tool there, but the same argument doesn't
> hold for Windows.
It seems that we could reach a consensus. The patch is attached. I'll add
thi
På fredag 05. august 2016 kl. 01:01:06, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>:
I wrote:
> Looking around, there are a couple of places outside commands/analyze.c
> that are making the same mistake, so this patch isn't complete, but it
> illustrates what needs to be done.
Here's a more com
Hello
I recently hit a road blocker when I tried to create a truncate trigger on
a foreign table. trigger.c::CreateTrigger() function has explicit check to
block truncate trigger on foreign tables.
However, trigger.c::ExecuteTruncate() does not seem to have any problems
issuing before/after trigg
On 5 August 2016 at 08:54, Anastasia Lubennikova
wrote:
> Working on page compression and some other issues related to
> access methods, I found out that the code related to heap
> looks too complicated. Much more complicated, than it should be.
> Since I anyway got into this area, I want to sugge
1 - 100 of 105 matches
Mail list logo
