On Tuesday, June 18, 2013 12:18 AM Sawada Masahiko wrote:
> On Sun, Jun 16, 2013 at 2:00 PM, Amit kapila
> wrote:
> > On Saturday, June 15, 2013 8:29 PM Sawada Masahiko wrote:
> > On Sat, Jun 15, 2013 at 10:34 PM, Amit kapila
> wrote:
> >>
> >> On Saturday, June 15, 2013 1:19 PM Sawada Masahiko w
On Tuesday, May 21, 2013, Simon Riggs wrote:
> I worked up a small patch to support Terabyte setting for memory.
> Which is OK, but it only works for 1TB, not for 2TB or above.
>
I've incorporated my review into a new version, attached.
Added "TB" to the docs, added the macro KB_PER_TB, and made
On Sun, Jun 16, 2013 at 11:54 AM, Jeff Janes
> wrote:
> In 9.3 HEAD I am getting what seems to be spurious wrap-around shutdowns.
>
>
> postgres=# SELECT datname, datfrozenxid, age(datfrozenxid) FROM
> pg_database;
>
> datname | datfrozenxid |age
> ---+--+---
>
On Mon, 2013-06-17 at 17:11 -0700, Josh Berkus wrote:
> Contributors,
>
> While going through this mailing list looking for missing 9.4 patches, I
> realized that we don't track backpatches (that is, fixes to prior
> versions) at all anywhere. Where backpatches are submitted by
> committers this
On Fri, 2013-06-14 at 17:00 -0400, Robert Haas wrote:
> Alvaro's work on 9.3, we now have the ability to configure background
> workers via shared_preload_libraries. But if you don't have the right
> library loaded at startup time, and subsequently wish to add a
> background worker while the serve
On Wed, 2013-06-12 at 16:31 -0300, Fabrízio de Royes Mello wrote:
> > Btw., I also want REPLACE BUT DO NOT CREATE.
>
> Can you explain more about it?
>
Replace/alter the object if it already exists, but fail if it does not
exist.
The complete set of variants is:
- object does not exist:
-
Thanks !
PFA the updated patch. Also remove a trailing whitespace at the end of SQL
script.
--
Robins Tharakan
On 17 June 2013 17:29, Szymon Guz wrote:
> On 26 May 2013 19:56, Robins Tharakan wrote:
>
>> Hi,
>>
>> Please find attached a patch to take code-coverage of SET (SESSION / SEED
>> /
Contributors,
While going through this mailing list looking for missing 9.4 patches, I
realized that we don't track backpatches (that is, fixes to prior
versions) at all anywhere. Where backpatches are submitted by
committers this isn't an issue, but we had a couple major ones (like the
autovacuu
On Tue, Jun 18, 2013 at 9:00 AM, Josh Berkus wrote:
>
>> Just wondering, how many patches did you add? 8? I saw a total of 98
>> patches a couple of days ago, now up to 106.
>
> Then it must be 8. That sounds a about right. Mind you, I immediately
> marked 2 as already committed.
Just did the sa
> Just wondering, how many patches did you add? 8? I saw a total of 98
> patches a couple of days ago, now up to 106.
Then it must be 8. That sounds a about right. Mind you, I immediately
marked 2 as already committed.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via
On Tue, Jun 18, 2013 at 7:41 AM, Josh Berkus wrote:
> Folks,
>
> At this stage, all of the patches which where not already added into CF1
> should be there. So look carefully and make sure *all* of your patches
> are there.
>
> Amusingly, it's not the new submitters who forgot to add their patch
Hackers,
I got a question on RRR which I thought should be addressed on this
list. Basically, the questioner asked me "I have a day job, I can't
promise to review all of these patches in 5 days".
The answer is: only put your name down on patches which you *can* review
in the next 5 days. Don't
BTW, one of the ideas that popped up in the unConference session on
replication was "why couldn't we use a background worker as a replication
agent?"
The main reason pointed out was 'because that means you have to restart the
postmaster to add a replication agent.' (e.g. - like a Slony "slon"
pro
Folks,
At this stage, all of the patches which where not already added into CF1
should be there. So look carefully and make sure *all* of your patches
are there.
Amusingly, it's not the new submitters who forgot to add their patch to
the CF, but rather experienced contributors, and even a commit
On 06/18/2013 04:58 AM, Peter Eisentraut wrote:
> On 6/14/13 11:48 PM, Craig Ringer wrote:
>> I wonder if that should be extended to install headers for hstore,
>> ltree, and while we're at it, intarray as well?
> Sure, if someone wants to go through and check which headers are
> independently usab
On 06/18/2013 01:25 AM, Pavel Stehule wrote:
>> > and also one called
>> > UPDATED
>> > which would have two row vars called OLD and NEW
>> > so you would access it like e.g. IF UPDATED.OLD.id = 7
>> >
> nice idea
>
> +1
Much better naming than OLD_AND_NEW.
I'm not so sure about
OLD
NEW
INSERTED
Hi!
This sounds really interesting, so a few quick comments.
On 15.6.2013 00:28, Alvaro Herrera wrote:
> In each index tuple (corresponding to one page range), we store: -
> first block this tuple applies to - last block this tuple applies to
> - for each indexed column: * min() value across al
Peter Eisentraut wrote:
> A transform is an SQL object that supplies to functions for converting
> between data types and procedural languages. For example, a transform
> could arrange that hstore is converted to an appropriate hash or
> dictionary object in PL/Perl or PL/Python.
>
> Externally v
On 6/14/13 11:48 PM, Craig Ringer wrote:
> I wonder if that should be extended to install headers for hstore,
> ltree, and while we're at it, intarray as well?
Sure, if someone wants to go through and check which headers are
independently usable, and do the necessarily cleanups with necessary.
On 2013-06-17 13:46:07 -0700, Josh Berkus wrote:
> On 06/17/2013 01:40 PM, Alvaro Herrera wrote:
> > Andres Freund wrote:
> >
> >> PS: Josh, minor thing, but could you please not trim the CC list, at
> >> least when I am on it?
> >
> > Yes, it's annoying.
>
> I also get private comments from peo
On 06/17/2013 01:40 PM, Alvaro Herrera wrote:
> Andres Freund wrote:
>
>> PS: Josh, minor thing, but could you please not trim the CC list, at
>> least when I am on it?
>
> Yes, it's annoying.
I also get private comments from people who don't want me to cc them
when they are already on the list.
Andres Freund wrote:
> PS: Josh, minor thing, but could you please not trim the CC list, at
> least when I am on it?
Yes, it's annoying.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing li
>> This begins to sound like these indexes are only useful on append-only
>> tables. Not that there aren't plenty of those, but ...
>
> But what?
... "but" the other comments further down in my email. Also, my
successive comments in other emails.
>> Why? Why can't we just update the affect
Tom Lane wrote:
> We've talked a lot about index-organized tables in the past. How much
> of the use case for this would be subsumed by a feature like that?
IOTs are not flexible enough. You can only have one index that you
index-organize the table on; and you can search only based on a prefix
On 2013-06-17 16:23:40 -0400, Alvaro Herrera wrote:
> > > Re-summarization is relatively expensive, because the complete page range
> > > has
> > > to be scanned.
> >
> > Why? Why can't we just update the affected pages in the index?
>
> The page range has to be scanned in order to find out the
Josh Berkus wrote:
> > Value changes in columns that are part of a minmax index, and tuple
> > insertion
> > in summarized pages, would invalidate the stored min/max values. To support
> > this, each minmax index has a validity map; a range can only be considered
> > in a
> > scan if it hasn't
Greg Stark wrote:
> On Fri, Jun 14, 2013 at 11:28 PM, Alvaro Herrera
> wrote:
> > Re-summarization is relatively expensive, because the complete page range
> > has
> > to be scanned.
>
> That doesn't sound too bad to me. It just means there's a downside to
> having larger page ranges. I would ex
On 2013-06-17 12:52:36 -0700, Josh Berkus wrote:
>
> > Well, it can do lots stuff that DROP/CREATE CONCURRENTLY can't:
> > * reindex primary keys
> > * reindex keys referenced by foreign keys
> > * reindex exclusion constraints
> > * reindex toast tables
> > * do all that for a whole database
> >
Simon Riggs wrote:
> On 9 June 2013 12:58, Craig Ringer wrote:
>> We don't currently have OLD and NEW relations so we're free to
>> define how this works pretty freely.
> I think the best way, if we did do this, would be to have a
> number of different relations defined:
>
> OLD
> NEW
> INSERTE
> Well, it can do lots stuff that DROP/CREATE CONCURRENTLY can't:
> * reindex primary keys
> * reindex keys referenced by foreign keys
> * reindex exclusion constraints
> * reindex toast tables
> * do all that for a whole database
> so I don't think that comparison is fair. Having it would have ma
On 06/17/2013 04:13 AM, Heikki Linnakangas wrote:
> On 14.06.2013 19:05, Kevin Grittner wrote:
>> Attached is a patch for REFRESH MATERIALIZED VIEW CONCURRENTLY for
>> 9.4 CF1. The goal of this patch is to allow a refresh without
>> interfering with concurrent reads, using transactional semantics.
> So there isn't a "fall down" thing here. We expect the recently
> loaded/updated data to be scanned and that's OK.
>
> Having the minmax index updated greedily is just adding extra work for
> fast diminishing returns. We can always add that later if really
> needed, but I doubt it will be neede
On Sun, Jun 16, 2013 at 2:00 PM, Amit kapila wrote:
> On Saturday, June 15, 2013 8:29 PM Sawada Masahiko wrote:
> On Sat, Jun 15, 2013 at 10:34 PM, Amit kapila wrote:
>>
>> On Saturday, June 15, 2013 1:19 PM Sawada Masahiko wrote:
>> On Fri, Jun 14, 2013 at 10:15 PM, Amit Kapila wrote:
>>> On Fr
Amit,
> I am interested in assisting you for this CF.
> Kindly let me know how can I add value for CommitFest management.
Thank you for the offer! However, you're currently signed up to review
several patches, and I'd rather have you doing that than sending out
reminder emails.
--
Josh Berkus
On 17.06.2013 15:56, Alexander Korotkov wrote:
On Sat, Jun 15, 2013 at 3:02 AM, Alexander Korotkovwrote:
This patch introduces new interface method of GIN which takes same
arguments as consistent but returns float8.
float8 gin_ordering(bool check[], StrategyNumber n, Datum query, int32
nkeys, P
On Mon, Jun 17, 2013 at 9:23 PM, Michael Paquier
wrote:
>
>
>
> On Mon, Jun 17, 2013 at 5:23 AM, Andres Freund
> wrote:
>>
>> On 2013-06-17 04:20:03 +0900, Fujii Masao wrote:
>> > On Thu, Jun 6, 2013 at 1:29 PM, Michael Paquier
>> > wrote:
>> > > Hi all,
>> > >
>> > > Please find attached the la
2013/6/17 Simon Riggs :
> On 9 June 2013 12:58, Craig Ringer wrote:
>> On 06/09/2013 04:58 PM, Simon Riggs wrote:
>>> There are also difficulties in semantics, since when
>>> we have OLD and NEW at row level we know we are discussing the same
>>> row. With sets of OLD and NEW we'd need to be able
On 17 June 2013 15:41, Kevin Grittner wrote:
> While I have yet to look in detail at the mechanism for capturing
> the initial delta on the base tables, the two fairly obvious
> candidates are to stuff the before and after images into a
> tuplestore or temp table as base table changes are written
Le lundi 17 juin 2013 18:41:32, Alvaro Herrera a écrit :
> Joe Conway wrote:
> > On 06/15/2013 11:28 AM, Alvaro Herrera wrote:
> > > This use case seems too narrow to me to justify the burden of
> > > keeping PGXS-enabled makefiles in contrib.
> >
> > What was the burden of it?
>
> Per http://www
On 17 June 2013 15:41, Kevin Grittner wrote:
> Since there seems to be interest in discussing incremental
> maintenance of materialized views *now*
Since your earlier complaint, I specificaly said I was happy to wait
to discuss that. Why have you raised this now?
--
Simon Riggs
Joe Conway wrote:
> On 06/15/2013 11:28 AM, Alvaro Herrera wrote:
> > This use case seems too narrow to me to justify the burden of
> > keeping PGXS-enabled makefiles in contrib.
>
> What was the burden of it?
Per
http://www.postgresql.org/message-id/1371093408.309.5.ca...@vanquo.pezone.net :
On Jun 16, 2013, at 9:20 AM, Cédric Villemain wrote:
>> Then instead of the above you'd just be able to say something like
>>
>> MODULETEST = test
>
> or REGRESSDIR ?
Yeah, that sounds perfect.
> Also I suggest to remove the need to set REGRESS at all, and default to all
> sql files in R
On Mon, Jun 17, 2013 at 11:21 AM, Kevin Grittner wrote:
> Nicolas Barbier wrote:
>> 2013/6/17 Heikki Linnakangas :
>
>>
>>> +errmsg("concurrent refresh requires a
>>> unique index on just columns for all rows of the materialized view")));
>>
>> Maybe my english is
On Sat, Jun 15, 2013 at 9:37 PM, Alvaro Herrera
wrote:
> Nicholas White escribió:
>
>> For the parsing changes, it seems I can either make RESPECT and IGNORE
>> reserved keywords, or add a lookahead to construct synthetic RESPECT NULLS
>> and IGNORE NULLS keywords. The grammar wouldn't compile if
Nicolas Barbier wrote:
> 2013/6/17 Heikki Linnakangas :
>
>> + errmsg("concurrent refresh requires a
>> unique index on just columns for all rows of the materialized view")));
>
> Maybe my english is failing me here, but I don’t understand the “just” part.
It means
On 2013-06-17 16:41 +02:00, Kevin Grittner wrote:
Since there seems to be interest in discussing incremental
maintenance of materialized views *now*, I'm starting this thread
to try to avoid polluting unrelated threads with the discussion. I
don't intend to spend a lot of time on it until the CF
On 2013-06-17 11:03:35 -0400, Peter Eisentraut wrote:
> On 6/17/13 9:19 AM, Andres Freund wrote:
> >> Without getting rid of the AccessExclusiveLock, REINDEX CONCURRENTLY is
> >> not really concurrent, at least not concurrent to the standard set by
> >> CREATE and DROP INDEX CONCURRENTLY.
> >
> >
On 6/17/13 9:19 AM, Andres Freund wrote:
>> Without getting rid of the AccessExclusiveLock, REINDEX CONCURRENTLY is
>> not really concurrent, at least not concurrent to the standard set by
>> CREATE and DROP INDEX CONCURRENTLY.
>
> Well, it still does the main body of work in a concurrent fashion,
Since there seems to be interest in discussing incremental
maintenance of materialized views *now*, I'm starting this thread
to try to avoid polluting unrelated threads with the discussion. I
don't intend to spend a lot of time on it until the CF in progress
completes, but at that point the work w
Hi,
When postgres on linux receives connection on a high rate client
connections sometimes error out with:
could not send data to server: Transport endpoint is not connected
could not send startup packet: Transport endpoint is not connected
To reproduce start something like on a server with suffi
2013/6/17 Heikki Linnakangas :
> +errmsg("concurrent refresh requires a
> unique index on just columns for all rows of the materialized view")));
Maybe my english is failing me here, but I don’t understand the “just” part.
Nicolas
--
A. Because it breaks the logi
On 2013-06-17 09:12:12 -0400, Peter Eisentraut wrote:
> On 6/17/13 8:23 AM, Michael Paquier wrote:
> > As mentionned by Andres, the only thing that the MVCC catalog patch can
> > improve here
> > is the index swap phase (index_concurrent_swap:index.c) where the
> > relfilenode of the
> > old and ne
Simon Riggs wrote:
> Kevin Grittner wrote:
>> Changeset extraction has nothing to do with this patch, and
>> cannot possibly be useful for it. Please keep discussion which
>> is completely unrelated to this patch off this thread.
> You mentioned "incremental maintenance" in your original post
On 6/17/13 8:23 AM, Michael Paquier wrote:
> As mentionned by Andres, the only thing that the MVCC catalog patch can
> improve here
> is the index swap phase (index_concurrent_swap:index.c) where the
> relfilenode of the
> old and new indexes are exchanged. Now an AccessExclusiveLock is taken
> on
On 9 June 2013 12:58, Craig Ringer wrote:
> On 06/09/2013 04:58 PM, Simon Riggs wrote:
>> There are also difficulties in semantics, since when
>> we have OLD and NEW at row level we know we are discussing the same
>> row. With sets of OLD and NEW we'd need to be able to link the
>> relations back
On 17.06.2013 15:55, Alexander Korotkov wrote:
On Sat, Jun 15, 2013 at 2:55 AM, Alexander Korotkovwrote:
attached patch implementing "fast scan" technique for GIN. This is second
patch of GIN improvements, see the 1st one here:
http://www.postgresql.org/message-id/capphfduxv-il7aedwpw0w5fxrwga
Heikki Linnakangas wrote:
> On 14.06.2013 19:05, Kevin Grittner wrote:
>> Attached is a patch for REFRESH MATERIALIZED VIEW CONCURRENTLY
>> for 9.4 CF1. The goal of this patch is to allow a refresh
>> without interfering with concurrent reads, using transactional
>> semantics.
>>
>> It is my hope
On Sat, Jun 15, 2013 at 3:02 AM, Alexander Korotkov wrote:
> attached patch implementing ordering inside GIN index. This is third patch
> of GIN improvements, see previous two:
>
> http://www.postgresql.org/message-id/capphfduxv-il7aedwpw0w5fxrwgakfxijwm63_hzujacrxn...@mail.gmail.com
>
> http://ww
On Sat, Jun 15, 2013 at 2:55 AM, Alexander Korotkov wrote:
> attached patch implementing "fast scan" technique for GIN. This is second
> patch of GIN improvements, see the 1st one here:
>
> http://www.postgresql.org/message-id/capphfduxv-il7aedwpw0w5fxrwgakfxijwm63_hzujacrxn...@mail.gmail.com
> Th
On 17 June 2013 13:15, Kevin Grittner wrote:
> Simon Riggs wrote:
>
>> There are multiple features all requiring efficient change set
>> extraction. It seems extremely relevant to begin discussing what
>> that mechanism might be in each case
>
> Changeset extraction has nothing to do with this pa
On Fri, Jun 14, 2013 at 12:09 AM, Alexander Korotkov
wrote:
> Revised version of patch for additional information storage in GIN is
> attached. Changes are mostly bug fixes.
>
New version of patch is attached with some more refactoring and bug fixes.
--
With best regards,
Alexander Korotkov.
On Fri, Mar 8, 2013 at 11:58 AM, Pavel Stehule wrote:
> I'll see - please, stay tuned to 9.4 first commitfest
Hi Pavel,
Just a reminder, I didn't see this patch in the current commitfest. I
would be happy to spend some more time reviewing if you wish to pursue
the patch.
Josh
--
Sent via pgs
On Mon, May 13, 2013 at 2:58 AM, Robins Tharakan wrote:
> Please find attached a patch that adds basic regression tests for DISCARD
> command.
>
> Any and all feedback is obviously welcome.
Perhaps existing tests in guc.sql should be merged into it?
--
marko
--
Sent via pgsql-hackers mailing
* David Fetter (da...@fetter.org) wrote:
> On Mon, Feb 11, 2013 at 10:48:38AM -0800, David Fetter wrote:
> > On Sun, Feb 10, 2013 at 10:09:19AM -0500, Tom Lane wrote:
> > > David Fetter writes:
> > > > Per suggestions and lots of help from Andrew Gierth, please find
> > > > attached a patch to cle
On Mon, Jun 17, 2013 at 5:23 AM, Andres Freund wrote:
> On 2013-06-17 04:20:03 +0900, Fujii Masao wrote:
> > On Thu, Jun 6, 2013 at 1:29 PM, Michael Paquier
> > wrote:
> > > Hi all,
> > >
> > > Please find attached the latest versions of REINDEX CONCURRENTLY for
> the 1st
> > > commit fest of 9.4
On 17 June 2013 12:13, Heikki Linnakangas wrote:
> On 14.06.2013 19:05, Kevin Grittner wrote:
>>
>> Attached is a patch for REFRESH MATERIALIZED VIEW CONCURRENTLY for
>> 9.4 CF1. The goal of this patch is to allow a refresh without
>> interfering with concurrent reads, using transactional semanti
Simon Riggs wrote:
> There are multiple features all requiring efficient change set
> extraction. It seems extremely relevant to begin discussing what
> that mechanism might be in each case
Changeset extraction has nothing to do with this patch, and cannot
possibly be useful for it. Please keep
On 2013-06-03 14:57:12 -0400, Robert Haas wrote:
> On Thu, May 30, 2013 at 1:39 AM, Michael Paquier
> wrote:
> > +1.
>
> Here's a more serious patch for MVCC catalog access. This one
> involves more data copying than the last one, I think, because the
> previous version did not register the snap
On 26 May 2013 19:56, Robins Tharakan wrote:
> Hi,
>
> Please find attached a patch to take code-coverage of SET (SESSION / SEED
> / TRANSACTION / DATESTYLE / TIME ZONE) (src/backend/commands/variable.c)
> from 65% to 82%.
>
> Any and all feedback is welcome.
> --
> Robins Tharakan
>
>
> --
> Sen
On Mon, Jun 17, 2013 at 11:34:52AM +0100, Dean Rasheed wrote:
> On 15 June 2013 10:22, Dean Rasheed wrote:
> > There seem to be 2 separate directions that this could go, which
> > really meet different requirements:
> >
> > 1). Produce an unordered sum for SQL to compare 2 tables regardless of
> >
On 17 June 2013 09:03, Pavan Deolasee wrote:
> I agree. We should probably find a better name for this. Any suggestions ?
err, I already made one...
>> But that's not the whole story. I can see some utility in a patch that
>> makes all WAL transfer synchronous, rather than just commits. Some
>>
This is a review of the patch in 5192d7d2.8020...@catalyst.net.nz
The patch applies cleanly (with the exception of catversion.h of course),
compiles without warnings and passes the regression tests.
It contains enough documentation, though I'd prefer
"Estimated number of rows modified since the t
On 14.06.2013 19:05, Kevin Grittner wrote:
Attached is a patch for REFRESH MATERIALIZED VIEW CONCURRENTLY for
9.4 CF1. The goal of this patch is to allow a refresh without
interfering with concurrent reads, using transactional semantics.
It is my hope to get this committed during this CF to all
On 15 June 2013 10:22, Dean Rasheed wrote:
> There seem to be 2 separate directions that this could go, which
> really meet different requirements:
>
> 1). Produce an unordered sum for SQL to compare 2 tables regardless of
> the order in which they are scanned. A possible approach to this might
>
On 23 May 2013 00:34, Robins Tharakan wrote:
> Hi,
>
> Please find attached a patch to take code-coverage of CREATE OPERATOR
> (src/backend/commands/operatorcmds.c) from 56% to 91%.
>
> Any and all feedback is welcome.
> --
> Robins Tharakan
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-h
Hi,
Peter Eisentraut writes:
> 2. confuse users
> 3. produce broken external extension modules that take contrib as an example
I agree that having both cases (sections) in the Makefile is a bad idea.
Still, why should we keep the in-tree build instructions?
Would it be possible instead to instr
Peter Eisentraut writes:
> I suspect that there are actually only about 5 or 6 common ways to do
> archiving (say, local, NFS, scp, rsync, S3, ...). There's no reason why
> we can't fully specify and/or script what to do in each of these cases.
And provide either fully reliable contrib scripts o
On Mon, Jun 17, 2013 at 1:22 PM, Soroosh Sardari
wrote:
> Hey
>
> I was reading the multi transaction log manager, multixact.c.
> I didn't get what SLRU does.
>
> I want the goal of this module, and why we use it.
> I'm kind of newbie, be patient with me ;)
>
>
Did you look at src/backend/access/
On Sun, Jun 16, 2013 at 5:10 PM, Simon Riggs wrote:
>
>
> My perspective is that if the master crashed, assuming that you know
> everything about that and suddenly jumping back on seem like a recipe
> for disaster. Attempting that is currently blocked by the technical
> obstacles you've identifie
Hey
I was reading the multi transaction log manager, multixact.c.
I didn't get what SLRU does.
I want the goal of this module, and why we use it.
I'm kind of newbie, be patient with me ;)
Regards
Soroosh
On 17 June 2013 02:05, Josh Berkus wrote:
>
>>> I agree that the FSM behaviour shouldn't be linked to index existence.
>>> IMHO that should be a separate table parameter, WITH (fsm_mode = append)
>>> Index only scans would also benefit from that.
>>
>> -1 ... I cannot believe that such a parameter
(2013/06/17 5:48), Andres Freund wrote:> On 2013-06-16 17:27:56 +0300, Heikki
Linnakangas wrote:
>> If we don't mind scanning the buffer cache several times, we don't
>> necessarily even need to sort the writes for that. Just scan the buffer
>> cache for all buffers belonging to relation A, then
On Mon, Jun 17, 2013 at 2:18 AM, Andres Freund wrote:
> On 2013-06-16 17:27:56 +0300, Heikki Linnakangas wrote:
>
> > A long time ago, Itagaki wrote a patch to sort the checkpoint writes:
> www.postgresql.org/message-id/flat/20070614153758.6a62.itagaki.takah...@oss.ntt.co.jp
> .
> > He posted very
On 17 June 2013 00:43, Kevin Grittner wrote:
>> Especially when one is known to be better than the other already.
>
> What is the hypothetical technique you're arguing is inferior? For
> my own part, I haven't gotten beyond the phase of knowing that to
> meet all requests for the feature, it wou
Thank you for giving comments and my patch reviewer!
(2013/06/16 23:27), Heikki Linnakangas wrote:
On 10.06.2013 13:51, KONDO Mitsumasa wrote:
I create patch which is improvement of checkpoint IO scheduler for
stable transaction responses.
* Problem in checkpoint IO schedule in heavy transacti
85 matches
Mail list logo
