> On 17 Aug 2017, at 11:08, Daniel Gustafsson wrote:
>
>> On 16 Aug 2017, at 17:51, Tom Lane wrote:
>>
>> Heikki Linnakangas writes:
>>> This no longer works:
>>
>>> postgres=# CREATE TEXT SEARCH DICTIONARY public.simple_dict (
>>>TEMPLATE = pg_catalog.simple,
>>>"STOPWORds" = english
> On 16 Aug 2017, at 17:51, Tom Lane wrote:
>
> Heikki Linnakangas writes:
>> This no longer works:
>
>> postgres=# CREATE TEXT SEARCH DICTIONARY public.simple_dict (
>> TEMPLATE = pg_catalog.simple,
>> "STOPWORds" = english
>> );
>> ERROR: unrecognized simple dictionary parameter: "ST
On Wed, Aug 16, 2017 at 11:51 AM, Tom Lane wrote:
> You have a point, but I'm not sure that this is such a bad compatibility
> break as to be a reason not to change things to be more consistent.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Heikki Linnakangas writes:
> This no longer works:
> postgres=# CREATE TEXT SEARCH DICTIONARY public.simple_dict (
> TEMPLATE = pg_catalog.simple,
> "STOPWORds" = english
> );
> ERROR: unrecognized simple dictionary parameter: "STOPWORds"
> In hindsight, perhaps we should always have
On 04/04/2017 10:13 AM, Daniel Gustafsson wrote:
On 04 Apr 2017, at 05:52, Alvaro Herrera wrote:
Daniel Gustafsson wrote:
Testing DefElem options is done with both strcmp() and pg_strcasecmp() a bit
mixed. Since the option defnames are all lowercased, either via IDENT, keyword
rules or “by ha
> On 04 Apr 2017, at 05:52, Alvaro Herrera wrote:
>
> Daniel Gustafsson wrote:
>> Testing DefElem options is done with both strcmp() and pg_strcasecmp() a bit
>> mixed. Since the option defnames are all lowercased, either via IDENT,
>> keyword
>> rules or “by hand” with makeString(), using strc
Daniel Gustafsson wrote:
> Testing DefElem options is done with both strcmp() and pg_strcasecmp() a bit
> mixed. Since the option defnames are all lowercased, either via IDENT,
> keyword
> rules or “by hand” with makeString(), using strcmp() is safe (and assumed to
> be
> so in quite a lot of pl
Testing DefElem options is done with both strcmp() and pg_strcasecmp() a bit
mixed. Since the option defnames are all lowercased, either via IDENT, keyword
rules or “by hand” with makeString(), using strcmp() is safe (and assumed to be
so in quite a lot of places).
While it’s not incorrect per se
On Thu, Feb 2, 2017 at 4:05 AM, Robert Haas wrote:
> On Tue, Jan 31, 2017 at 8:26 PM, Michael Paquier
> wrote:
>> pq_sendcountedtext() does some encoding conversion, which is why I
>> haven't used because we deal only with integers in this patch... Now
>> if you wish to switch to that I have real
On Tue, Jan 31, 2017 at 8:26 PM, Michael Paquier
wrote:
> pq_sendcountedtext() does some encoding conversion, which is why I
> haven't used because we deal only with integers in this patch... Now
> if you wish to switch to that I have really no arguments against.
OK, I see. Well, I guess it's se
On Tue, Jan 31, 2017 at 11:59 PM, Robert Haas wrote:
> Sorry, I have a little more nitpicking.
Thanks for the input.
> How about having
> printsimple() use pq_sendcountedtext() instead of pq_sendint()
> followed by pq_sendbytes(), as it does for TEXTOID?
>
> Other than that, this looks fine to m
On Tue, Jan 31, 2017 at 12:19 AM, Michael Paquier
wrote:
> This is a follow up of the refactoring that has been discussed in the
> thread to increase the default size of WAL segments:
> https://www.postgresql.org/message-id/cab7npqq4hynrlq+w1jrryvsysoxuqa40pyb2uw5uqkkag4h...@mail.gmail.com
>
> The
Hi all,
This is a follow up of the refactoring that has been discussed in the
thread to increase the default size of WAL segments:
https://www.postgresql.org/message-id/cab7npqq4hynrlq+w1jrryvsysoxuqa40pyb2uw5uqkkag4h...@mail.gmail.com
The discussion has resulted in the creation of a84069d9 that
On Tue, Sep 27, 2016 at 2:13 PM, Tom Lane wrote:
> I can see the value of processing unique indexes before non-unique ones.
> I'm pretty suspicious of trying to prioritize primary keys first, though,
> because (a) it's not clear why bother, and (b) PG is a tad squishy about
> whether an index is a
Heikki Linnakangas writes:
> On 09/24/2016 02:34 PM, Peter Geoghegan wrote:
>> I go on to explain how this patch represents a partial solution to
>> that [1]. That's what I mean by "useful practical consequences". As I
>> say in [1], I think we could even get a full solution, if we applied
>> this
On 09/27/2016 11:38 AM, Peter Geoghegan wrote:
On Tue, Sep 27, 2016 at 9:25 AM, Heikki Linnakangas wrote:
I didn't think very hard about it, but yeah, think so..
Do you think it's worth a backpatch? Or, too early to tell?
Too early to tell..
- Heikki
--
Sent via pgsql-hackers mailing li
On Tue, Sep 27, 2016 at 9:25 AM, Heikki Linnakangas wrote:
> I didn't think very hard about it, but yeah, think so..
Do you think it's worth a backpatch? Or, too early to tell?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
On 09/27/2016 11:22 AM, Peter Geoghegan wrote:
On Tue, Sep 27, 2016 at 9:10 AM, Heikki Linnakangas wrote:
Hmm, yeah, that'd be nice to fix. I'd like to see a patch specifically to
fix that. I'm not convinced that we need all the complications of this
patch, to get that fixed. (In particular, in
On Tue, Sep 27, 2016 at 9:10 AM, Heikki Linnakangas wrote:
> Hmm, yeah, that'd be nice to fix. I'd like to see a patch specifically to
> fix that. I'm not convinced that we need all the complications of this
> patch, to get that fixed. (In particular, indexam's still wouldn't need to
> care about
On 09/24/2016 02:34 PM, Peter Geoghegan wrote:
On Tue, Sep 20, 2016 at 8:55 AM, Heikki Linnakangas wrote:
Likewise, in ExecInsertIndexTuples(), this makes the deferred-index
case work slightly differently from speculative insertion. It's not a big
difference, but it again forces you to keep one
On Tue, Sep 6, 2016 at 8:39 PM, Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
> 06.09.2016 07:44, Pavan Deolasee:
>
>
> I don't know what to do with the CF entry itself. I could change the
> status to "waiting on author" but then the design draft may not get enough
> attention. So I
On Tue, Sep 20, 2016 at 8:55 AM, Heikki Linnakangas wrote:
> Thanks for working on this, and sorry for disappearing and dropping this on
> the floor earlier. This doesn't apply anymore, thanks to 9c810a2e. Shouldn't
> be hard to fix.
Thanks for looking at it again.
> I was in support of this ear
On 03/17/2016 01:43 AM, Peter Geoghegan wrote:
I attach a revision, that makes all the changes that Heikki suggested,
except one. As already noted several times, following this suggestion
would have added a bug. Alvaro preferred my original approach here in
any case. I refer to my original approa
On Mon, Sep 12, 2016 at 7:12 PM, Pavan Deolasee
wrote:
> I was thinking about locking, bulk reading (like page-mode API) etc. While
> you've added an API for vacuuming, we would probably also need an API to
> collect dead tuples, pruning etc (not sure if that can be combined with
> vacuum). Of cou
On Tue, Sep 6, 2016 at 8:39 PM, Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
> 06.09.2016 07:44, Pavan Deolasee:
>
> 2. I don't understand the difference between PageGetItemHeapHeaderOnly()
> and PageGetItemHeap(). They seem to do exactly the same thing and can be
> used interchang
06.09.2016 07:44, Pavan Deolasee:
On Mon, Aug 8, 2016 at 3:13 PM, Anastasia Lubennikova
mailto:a.lubennik...@postgrespro.ru>>
wrote:
Thank you for the review, I'll fix these problems in final version.
Posting the first message I intended to raise the discussion. Patches
were
On Mon, Aug 8, 2016 at 3:13 PM, Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
>
>>
> Thank you for the review, I'll fix these problems in final version.
>
> Posting the first message I intended to raise the discussion. Patches
> were attached mainly to illustrate the problem and to
08.08.2016 12:43, Anastasia Lubennikova:
08.08.2016 03:51, Michael Paquier:
On Sat, Aug 6, 2016 at 2:56 AM, Alvaro Herrera
wrote:
Anastasia Lubennikova wrote:
So there is a couple of patches. They do not cover all mentioned
problems,
but I'd like to get a feedback before continuing.
I agree
Anastasia Lubennikova wrote:
> By the way, I thought about looking at the mentioned patch and
> probably reviewing it, but didn't find any of your patches on the
> current commitfest. Could you point out the thread?
Sorry, I haven't posted anything yet.
> >Agreed. But changing its name while ke
08.08.2016 03:51, Michael Paquier:
On Sat, Aug 6, 2016 at 2:56 AM, Alvaro Herrera wrote:
Anastasia Lubennikova wrote:
So there is a couple of patches. They do not cover all mentioned problems,
but I'd like to get a feedback before continuing.
I agree that we could improve things in this gener
05.08.2016 20:56, Alvaro Herrera:
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 sugg
On Sat, Aug 6, 2016 at 2:56 AM, Alvaro Herrera wrote:
> Anastasia Lubennikova wrote:
>> So there is a couple of patches. They do not cover all mentioned problems,
>> but I'd like to get a feedback before continuing.
>
> I agree that we could improve things in this general area, but I do not
> endo
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
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 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 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
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.
There is a number of problems I see i
On Tue, Apr 5, 2016 at 9:47 PM, Robert Haas wrote:
>> I do not pursue something like this without good reason. I'm
>> optimistic that the patch will be accepted if it is carefully
>> considered.
>
> This patch has attracted no reviewers. Any volunteers?
Since nobody has emerged to review this, I
On Wed, Mar 16, 2016 at 7:43 PM, Peter Geoghegan wrote:
> On Wed, Mar 16, 2016 at 11:25 AM, Robert Haas wrote:
>> Sure, and if everybody does that, then there will be 40 patches that
>> get updated in the last 2 days if the CommitFest, and that will be
>> impossible. Come on. You're demanding a
On Wed, Mar 16, 2016 at 11:25 AM, Robert Haas wrote:
> Sure, and if everybody does that, then there will be 40 patches that
> get updated in the last 2 days if the CommitFest, and that will be
> impossible. Come on. You're demanding a degree of preferential
> treatment which is unsupportable.
I
On Mon, Mar 14, 2016 at 8:17 PM, Peter Geoghegan wrote:
> On Mon, Mar 14, 2016 at 5:04 PM, Robert Haas wrote:
>> There hasn't been a new version of this patch in 9 months, you're
>> clearly not in a hurry to produce one, and nobody else seems to feel
>> strongly that this is something that needs
On Mon, Mar 14, 2016 at 5:21 PM, Andres Freund wrote:
> So? You're not the only one. I don't see why we shouldn't move this to
> 'returned with feedback' until there's a new version.
I don't see any point in that; I intend to get a revision in to the
ongoing CF. But fine.
--
Peter Geoghegan
-
On 2016-03-14 17:17:02 -0700, Peter Geoghegan wrote:
> On Mon, Mar 14, 2016 at 5:04 PM, Robert Haas wrote:
> > There hasn't been a new version of this patch in 9 months, you're
> > clearly not in a hurry to produce one, and nobody else seems to feel
> > strongly that this is something that needs t
On Mon, Mar 14, 2016 at 5:04 PM, Robert Haas wrote:
> There hasn't been a new version of this patch in 9 months, you're
> clearly not in a hurry to produce one, and nobody else seems to feel
> strongly that this is something that needs to be done at all. I think
> we could just let this go and be
On Sat, Mar 12, 2016 at 5:53 PM, Peter Geoghegan wrote:
> On Sat, Mar 12, 2016 at 2:43 PM, Michael Paquier
> wrote:
>> Only one version of this patch has been sent at the beginning of this
>> thread, and Heikki has clearly expressed his disagreement about at
>> least a portion of it at the beginn
On Sat, Mar 12, 2016 at 2:53 PM, Peter Geoghegan wrote:
> I said "basically uncontroversial", not "uncontroversial". That is a
> perfectly accurate characterization of the patch, and if you disagree
> than I suggest you re-read the thread.
In particular, note that Alvaro eventually sided with me
On Sat, Mar 12, 2016 at 2:43 PM, Michael Paquier
wrote:
> Only one version of this patch has been sent at the beginning of this
> thread, and Heikki has clearly expressed his disagreement about at
> least a portion of it at the beginning of this thread, so I find it
> hard to define it as an "unco
On Sat, Mar 12, 2016 at 11:24 PM, Peter Geoghegan wrote:
> On Fri, Mar 11, 2016 at 5:26 AM, Robert Haas wrote:
>> This patch was reviewed during CF 2016-01 and has not been updated for
>> CF 2016-03. I think we should mark it Returned with Feedback.
>
> I have a full plate at the moment, Robert,
On Fri, Mar 11, 2016 at 5:26 AM, Robert Haas wrote:
> This patch was reviewed during CF 2016-01 and has not been updated for
> CF 2016-03. I think we should mark it Returned with Feedback.
I have a full plate at the moment, Robert, both as a reviewer and as a
patch author. This patch is basicall
On Mon, Jan 18, 2016 at 3:14 PM, Peter Geoghegan wrote:
> On Mon, Jan 18, 2016 at 11:56 AM, Alvaro Herrera
> wrote:
>>> That's because I believe this is quite broken, as already pointed out.
>>
>> I think I like your approach better.
>
> That makes things far simpler, then.
>
>>> Your premise her
On Mon, Jan 18, 2016 at 11:56 AM, Alvaro Herrera
wrote:
>> That's because I believe this is quite broken, as already pointed out.
>
> I think I like your approach better.
That makes things far simpler, then.
>> Your premise here is that what Heikki said in passing months ago is
>> incontrovertib
Peter Geoghegan wrote:
> On Mon, Jan 18, 2016 at 8:36 AM, Alvaro Herrera
> wrote:
> > If you refuse to post an updated version of the patch until Heikki
> > weighs in some more, and given that Heikki has (for the purposes of this
> > patch) completely vanished, I think we should mark this rejected
On Mon, Jan 18, 2016 at 8:36 AM, Alvaro Herrera
wrote:
> If you refuse to post an updated version of the patch until Heikki
> weighs in some more, and given that Heikki has (for the purposes of this
> patch) completely vanished, I think we should mark this rejected.
I don't refuse. I just don't w
Peter Geoghegan wrote:
> On Fri, Dec 18, 2015 at 12:55 PM, Robert Haas wrote:
> > I only see one patch version on the thread.
>
> I'm not going to post a revision until I thrash out the tiny issues
> with Heikki. He kind of trailed off. So maybe that kills it
> immediately, which is a shame.
If
On Sat, Dec 19, 2015 at 3:26 PM, Michael Paquier
wrote:
> +1. There are folks around doing tests using 9.5 now, it is not
> correct to impact the effort they have been putting on it until now.
This is a total misrepresentation of what I've said.
--
Peter Geoghegan
--
Sent via pgsql-hackers m
On Sat, Dec 19, 2015 at 1:58 AM, Robert Haas wrote:
> No, it's far too late to be pushing this into 9.5. We are at RC1 now
> and hoping to cut a final release right after Christmas. I think it's
> quite wrong to argue that these changes have no risk of destabilizing
> 9.5. Nobody is exempt from
On Fri, Dec 18, 2015 at 12:55 PM, Robert Haas wrote:
> On Fri, Dec 18, 2015 at 2:04 PM, Peter Geoghegan wrote:
>> It isn't true that Heikki was not basically in favor of this. This
>> should have been committed as part of the original patch, really.
>
> Maybe he wasn't against the whole thing, bu
On Fri, Dec 18, 2015 at 2:04 PM, Peter Geoghegan wrote:
> It isn't true that Heikki was not basically in favor of this. This
> should have been committed as part of the original patch, really.
Maybe he wasn't against the whole thing, but he's posted two messages
to this thread and they can't be r
On Fri, Dec 18, 2015 at 8:58 AM, Robert Haas wrote:
> No, it's far too late to be pushing this into 9.5. We are at RC1 now
> and hoping to cut a final release right after Christmas. I think it's
> quite wrong to argue that these changes have no risk of destabilizing
> 9.5. Nobody is exempt from
On Thu, Dec 17, 2015 at 2:55 AM, Peter Geoghegan wrote:
> On Wed, Dec 16, 2015 at 11:44 PM, Peter Geoghegan wrote:
>>> In any case, at this point 9.5 is really aimed to be stabilized, so
>>> targeting only master is a far saner approach IMO for this patch.
>>> Pushing that in 9.5 a couple of mont
On Fri, Dec 18, 2015 at 4:31 PM, Peter Geoghegan wrote:
> On Thu, Dec 17, 2015 at 11:06 PM, Michael Paquier
> wrote:
>> Now per the two points listed in
>> the first sentence in this paragraph, perhaps this opinion is fine as
>> moot :) I didn't get much involved in the development of this code
>
On Thu, Dec 17, 2015 at 11:06 PM, Michael Paquier
wrote:
>> I should add: I think that the chances of this patch destabilizing the
>> code are very slim, once it receives the proper review. Certainly, I
>> foresee no possible downside to not inserting the doomed IndexTuple,
>> since it's guarantee
On Thu, Dec 17, 2015 at 4:55 PM, Peter Geoghegan wrote:
> On Wed, Dec 16, 2015 at 11:44 PM, Peter Geoghegan wrote:
>>> In any case, at this point 9.5 is really aimed to be stabilized, so
>>> targeting only master is a far saner approach IMO for this patch.
>>> Pushing that in 9.5 a couple of mont
On Wed, Dec 16, 2015 at 11:44 PM, Peter Geoghegan wrote:
>> In any case, at this point 9.5 is really aimed to be stabilized, so
>> targeting only master is a far saner approach IMO for this patch.
>> Pushing that in 9.5 a couple of months back may have given enough
>> reason to do so... But well l
On Wed, Dec 16, 2015 at 11:20 PM, Michael Paquier
wrote:
> (A couple of months later)
> This is not an actual fix, but an optimization, no?
> UNIQUE_CHECK_SPECULATIVE is just used to optimize a couple of code
> paths in the case of a insert conflicting during btree insertion..
>
> In any case, at
On Sun, Oct 4, 2015 at 2:07 AM, Peter Geoghegan wrote:
> On Sat, Oct 3, 2015 at 6:38 AM, Andres Freund wrote:
>> I'm not arguing against any of this - but I don't think this needs to be
>> on the 9.5 open items list. I plan to remove from there.
>
> Obviously I don't think that this is a critical
On Sat, Oct 3, 2015 at 6:38 AM, Andres Freund wrote:
> I'm not arguing against any of this - but I don't think this needs to be
> on the 9.5 open items list. I plan to remove from there.
Obviously I don't think that this is a critical fix. I do think that
it would be nice to keep the branches in
Hi,
On 2015-06-10 16:19:27 -0700, Peter Geoghegan wrote:
> Currently, speculative insertion (the INSERT ... ON CONFLICT DO UPDATE
> executor/storage infrastructure) uses checkUnique ==
> UNIQUE_CHECK_PARTIAL for unique indexes, which is a constant
> originally only used by deferred unique constrai
On Thu, Jul 2, 2015 at 2:58 PM, Peter Geoghegan wrote:
> As with row locking, with insertion, if there is a conflict, any
> outcome (UPDATE or INSERT) is then possible.
Where are we on this? It would be nice to get this out of the way
before a 9.5 beta is put out.
Thanks
--
Peter Geoghegan
--
On Thu, Jul 2, 2015 at 10:49 AM, Peter Geoghegan wrote:
> Well, waiting means getting a ShareLock on the other session's XID.
> You can't do that without first releasing your locks, unless you're
> okay with unprincipled deadlocks.
Besides, if the other session wins the race and inserts a physica
On Thu, Jul 2, 2015 at 1:30 AM, Heikki Linnakangas wrote:
>> Sure, if a speculative inserter detects a conflict, it still has to
>> wait. But not in the aminsert call, and not until it cleans up its
>> physical insertion (by super-deleting). Clearly a
>> CHECK_UNIQUE_SPECULATIVE would have to be m
On 07/01/2015 09:19 PM, Peter Geoghegan wrote:
On Wed, Jul 1, 2015 at 10:45 AM, Peter Geoghegan wrote:
On Tue, Jun 30, 2015 at 11:19 AM, Heikki Linnakangas wrote:
I agree it would be cleaner to have a separate CHECK_UNIQUE_XXX code for
speculative insertions. You've defined CHECK_UNIQUE_SPECU
On Wed, Jul 1, 2015 at 10:45 AM, Peter Geoghegan wrote:
> On Tue, Jun 30, 2015 at 11:19 AM, Heikki Linnakangas wrote:
>> I agree it would be cleaner to have a separate CHECK_UNIQUE_XXX code for
>> speculative insertions. You've defined CHECK_UNIQUE_SPECULATIVE as "like
>> CHECK_UNIQUE_PARTIAL, bu
On Wed, Jul 1, 2015 at 10:45 AM, Peter Geoghegan wrote:
> You can construct a theoretical case where lock starvation occurs with
> unique constraint enforcement. I think it helps with nbtree here that
> someone will reliably *not* see a conflict when concurrently
> inserting, because unique index
On Tue, Jun 30, 2015 at 11:19 AM, Heikki Linnakangas wrote:
> I agree it would be cleaner to have a separate CHECK_UNIQUE_XXX code for
> speculative insertions. You've defined CHECK_UNIQUE_SPECULATIVE as "like
> CHECK_UNIQUE_PARTIAL, but you don't have to insert the index tuple if
> there's a conf
On 06/11/2015 02:19 AM, Peter Geoghegan wrote:
Currently, speculative insertion (the INSERT ... ON CONFLICT DO UPDATE
executor/storage infrastructure) uses checkUnique ==
UNIQUE_CHECK_PARTIAL for unique indexes, which is a constant
originally only used by deferred unique constraints. It occurred
On Sat, Jun 27, 2015 at 5:10 PM, Tatsuo Ishii wrote:
> Main pgbench logic consists of single file pgbench.c which is 4036
> lines of code as of today. This is not a small number and I think it
> would be nice if it is divided into smaller files because it will make
> it easier to maintain, add or
This is kind of surprising to me that two people are against
refactoring proposal (I understand that Fabien has pending patches for
pgbench and that could be a motivation for this though).
I think that's a misunderstanding. I'm not against refactoring - not at all,
and neither is Fabien I be
On 06/28/15 18:56, Tatsuo Ishii wrote:
I do not think that this large file is a so big a problem (good
editors help navigation in the code), and I'm not sure that splitting
it would achieve much: there are not that many functions, some of
them are maybe long (main, threadRun, doCustom) but mostly
>> I do not think that this large file is a so big a problem (good
>> editors help navigation in the code), and I'm not sure that splitting
>> it would achieve much: there are not that many functions, some of
>> them are maybe long (main, threadRun, doCustom) but mostly for good
>> reasons.
>
> My
Hi,
On 06/28/2015 08:10 AM, Fabien COELHO wrote:
Hello Tatsuo,
Main pgbench logic consists of single file pgbench.c which is 4036
lines of code as of today. This is not a small number and I think
it would be nice if it is divided into smaller files because it
will make it easier to maintain,
Hello Tatsuo,
Main pgbench logic consists of single file pgbench.c which is 4036 lines
of code as of today. This is not a small number and I think it would be
nice if it is divided into smaller files because it will make it easier
to maintain, add or change features of pgbench.
I do not thi
Main pgbench logic consists of single file pgbench.c which is 4036
lines of code as of today. This is not a small number and I think it
would be nice if it is divided into smaller files because it will make
it easier to maintain, add or change features of pgbench. I will come
up with an idea how t
Currently, speculative insertion (the INSERT ... ON CONFLICT DO UPDATE
executor/storage infrastructure) uses checkUnique ==
UNIQUE_CHECK_PARTIAL for unique indexes, which is a constant
originally only used by deferred unique constraints. It occurred to me
that this has a number of disadvantages:
*
On Fri, Feb 13, 2015 at 10:26 PM, Heikki Linnakangas
wrote:
> In the "redesign checkpoint_segments" patch, Robert suggested keeping the
> settings' base unit as "number of segments", but allow conversions from MB,
> GB etc. I started looking into that and found that adding a new unit to
> guc.c is
On 2/13/15 11:44 AM, Heikki Linnakangas wrote:
On 02/13/2015 07:34 PM, Jim Nasby wrote:
On 2/13/15 7:26 AM, Heikki Linnakangas wrote:
In the "redesign checkpoint_segments" patch, Robert suggested keeping
the settings' base unit as "number of segments", but allow conversions
from MB, GB etc. I s
On 02/13/2015 07:34 PM, Jim Nasby wrote:
On 2/13/15 7:26 AM, Heikki Linnakangas wrote:
In the "redesign checkpoint_segments" patch, Robert suggested keeping
the settings' base unit as "number of segments", but allow conversions
from MB, GB etc. I started looking into that and found that adding a
On 2/13/15 7:26 AM, Heikki Linnakangas wrote:
In the "redesign checkpoint_segments" patch, Robert suggested keeping
the settings' base unit as "number of segments", but allow conversions
from MB, GB etc. I started looking into that and found that adding a new
unit to guc.c is quite messy. The con
In the "redesign checkpoint_segments" patch, Robert suggested keeping
the settings' base unit as "number of segments", but allow conversions
from MB, GB etc. I started looking into that and found that adding a new
unit to guc.c is quite messy. The conversions are done with complicated
if-switch
On Sat, Sep 20, 2014 at 1:16 PM, Michael Paquier
wrote:
> On Fri, Sep 19, 2014 at 12:18 PM, Robert Haas wrote:
>> On Tue, Sep 16, 2014 at 2:19 PM, Michael Paquier
>> wrote:
>>> - A patch refactoring code for pg_stat_get_wal_senders and
>>> SyncRepReleaseWaiters as there is in either case duplica
Heikki Linnakangas writes:
>> I'm not understanding the sequence difference well enough to comment
>> here, but I think some people are currently playing tricks in their
>> failover scripts with moving files directly to the pg_xlog of the server
>> to be promoted.
>
> That's still perfectly ok. It
On 30.11.2012 13:11, Dimitri Fontaine wrote:
Hi,
Heikki Linnakangas writes:
Attached is a patch to refactor that logic into a more straightforward state
machine. It's always been a kind of a state machine, but it's been hard to
see, as the code wasn't explicitly written that way. Any objection
On 29 November 2012 09:06, Heikki Linnakangas wrote:
> The code that reads the WAL from the archive, from pg_xlog, and from a
> master server via walreceiver, is quite complicated. I'm talking about the
> WaitForWALToBecomeAvailable() function in xlog.c. I got frustrated with that
> while working
Hi,
Heikki Linnakangas writes:
> Attached is a patch to refactor that logic into a more straightforward state
> machine. It's always been a kind of a state machine, but it's been hard to
> see, as the code wasn't explicitly written that way. Any objections?
On a quick glance over, looks good to
The code that reads the WAL from the archive, from pg_xlog, and from a
master server via walreceiver, is quite complicated. I'm talking about
the WaitForWALToBecomeAvailable() function in xlog.c. I got frustrated
with that while working on the "switching timeline over streaming
replication" pat
On Fri, Mar 23, 2012 at 7:41 PM, Marti Raudsepp wrote:
> Yeah, I'm still working on addressing the comments from your last email.
>
> Haven't had much time to work on it for the last 2 weeks, but I hope
> to finish most of it this weekend.
Since the updated patch seems never to have been posted,
On Sat, Mar 24, 2012 at 01:17, Tom Lane wrote:
> I've applied a slightly-modified version of this after reconciling it
> with the protransform fixes.
Cool, thanks!
> I assume you are going to submit a rebased
> version of the main CacheExpr patch?
Yeah, I'm still working on addressing the comme
Marti Raudsepp writes:
> Per Tom's request, I split out this refactoring from my CacheExpr patch.
> Basically I'm just centralizing the eval_const_expressions_mutator()
> call on function arguments, from multiple different places to a single
> location. Without this, it would be a lot harder to i
Hi list,
Per Tom's request, I split out this refactoring from my CacheExpr patch.
Basically I'm just centralizing the eval_const_expressions_mutator()
call on function arguments, from multiple different places to a single
location. Without this, it would be a lot harder to implement argument
cach
Simon Riggs writes:
> On Wed, Feb 1, 2012 at 10:42 PM, Jim Nasby wrote:
>> But we already had RelFileNode; wouldn't that be enough to tell what rmgr
>> was responsible for the new page? Can 2 different rmgrs write to the same
>> file node?
> No, but which one? No way to tell unless you have fu
1 - 100 of 205 matches
Mail list logo
