> Anyone who thinks the patches list should remain as separate from
> hackers, shout now (with rationale)!
Kill it now, long enough before the next patchfest for it to stick.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches m
f you want someone to do that you will probably need to hire a
development and support company, or do it yourself.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make chang
On Mon, 2008-09-29 at 11:24 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Mon, 2008-09-29 at 10:13 -0400, Tom Lane wrote:
> >> ... If we crash and restart, we'll have to get to the end
> >> of this file before we start letti
On Mon, 2008-09-29 at 10:13 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I think we can get away with writing the LSN value to disk, as you
> > suggested, but only every so often. No need to do it after every WAL
> > record, just consistently eve
On Mon, 2008-09-29 at 08:46 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > ... That kinda works, but the problem is that restartpoints are time based,
> > not log based. We need them to be deterministic for us to rely upon them
> > in the abo
On Sun, 2008-09-28 at 21:16 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> >> It does nothing AFAICS for the
> >> problem that when restarting archive recovery from a restartpoint,
> >> it's not clear when it is safe to start letting in
p() so do not experience
the need for that.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
On Wed, 2008-08-06 at 23:38 +0100, Simon Riggs wrote:
> On Wed, 2008-08-06 at 16:37 +0100, Simon Riggs wrote:
>
> > I'll submit the fully working plugin once we've stabilised the API. It's
> > designed as a contrib module, so it can go in pgfoundry or contr
On Fri, 2008-09-26 at 11:20 +0100, Simon Riggs wrote:
> > After reading this for awhile, I realized that there is a rather
> > fundamental problem with it: it switches into "consistent recovery"
> > mode as soon as it's read WAL beyond ControlFile->minRe
On Thu, 2008-09-25 at 18:28 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Version 7
> Anyway, that's sufficiently bad that I'm bouncing the patch for
> reconsideration.
No problem, I understand this needs discussion.
There's less d
On Wed, 2008-09-24 at 13:48 +0100, Simon Riggs wrote:
> On Tue, 2008-09-23 at 22:47 +0100, Simon Riggs wrote:
>
> > I've tested this some more and am much happier with it now.
>
> The concept is fine, but I've found a coding bug in further testing.
> Please
On Wed, 2008-09-24 at 12:04 -0400, Bruce Momjian wrote:
> Can we consider this hash thread closed/completed?
Please
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make chan
On Tue, 2008-09-23 at 22:47 +0100, Simon Riggs wrote:
> I've tested this some more and am much happier with it now.
The concept is fine, but I've found a coding bug in further testing.
Please wait now for new version before review.
--
Simon Riggs www.2ndQuadrant.co
On Thu, 2008-09-18 at 15:59 +0100, Simon Riggs wrote:
> On Tue, 2008-09-16 at 10:11 -0400, Alvaro Herrera wrote:
>
> > I wonder if the improved clog API required to mark multiple
> > transactions as committed at once would be also useful to
> > TransactionIdCommitTree
On Mon, 2008-09-22 at 23:06 +0100, Simon Riggs wrote:
> On Thu, 2008-09-18 at 10:09 -0400, Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > On Thu, 2008-09-18 at 09:06 -0400, Tom Lane wrote:
> > >> Do we really need a checkpoint there at all?
On Tue, 2008-09-23 at 09:13 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Thinks: Why not just sort all of the time and skip the debate entirely?
>
> The sort is demonstrably a loser for smaller indexes. Admittedly,
> if the index is small then
On Tue, 2008-09-23 at 09:13 -0400, Tom Lane wrote:
> The other side of that coin is that it's not clear this is really worth
> arguing about, much less exposing a separate parameter for.
Agreed.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services
On Tue, 2008-09-23 at 08:16 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > maintenance_work_mem is already used for 3 separate operations that bear
> > little resemblance to each other. If it's appropriate for all of those
> > then its
On Tue, 2008-09-23 at 00:48 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I wasn't very happy with effective_cache_size and not happy with
> > shared_buffers either. If building hash indexes is memory critical then
> > we just need to sa
mem
higher than shared buffers is easily possible now and we should just use
that rather than try to prejudge how people will and can configure their
systems. If maintenance_work_mem default is too low, lets increase it.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
On Thu, 2008-09-18 at 10:09 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Thu, 2008-09-18 at 09:06 -0400, Tom Lane wrote:
> >> Do we really need a checkpoint there at all?
>
> > "Timelines only change at shutdown checkpoints"
On Thu, 2008-09-18 at 10:09 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Thu, 2008-09-18 at 09:06 -0400, Tom Lane wrote:
> >> Do we really need a checkpoint there at all?
>
> > "Timelines only change at shutdown checkpoints"
On Thu, 2008-09-18 at 09:06 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Having some trouble trying to get a clean state change from recovery to
> > normal mode.
>
> > Startup needs to be able to write WAL at the end of recovery so it can
On Thu, 2008-09-18 at 09:05 +0100, Simon Riggs wrote:
> Feels like I should shutdown the bgwriter after recovery and then
> allow it to be cranked up again after normal processing starts, and do
> all of this through postmaster state changes. That way bgwriter
> doesn't nee
On Tue, 2008-09-16 at 15:45 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> wrote:
> > Testing takes a while on this, I probably won't complete it until
> > Friday. So enclosed patch is for eyeballs only at this stage.
>
> What's the status on that
On Tue, 2008-09-16 at 15:45 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> wrote:
> > Testing takes a while on this, I probably won't complete it until
> > Friday. So enclosed patch is for eyeballs only at this stage.
>
> What's the status on that p
On Fri, 2008-09-12 at 15:31 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
> >
> > All I changed was the word "restartpoint"... its otherwise identical to
> > existing message. I'd rather not change that.
>
> The new message is not translatabl
On Fri, 2008-09-12 at 14:14 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
> > --- 5716,5725
> > CheckpointStats.ckpt_sync_end_t,
> > &sync_secs, &sync_usecs);
>
es a while on this, I probably won't complete it until
Friday. So enclosed patch is for eyeballs only at this stage.
I added in the XLogCtl padding we've discussed before, while I'm there.
--
Simon Riggs www.2ndQ
On Mon, 2008-09-08 at 13:34 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Included patch with the following changes:
>
> > * new postmaster mode known as consistent recovery, entered only when
> > recovery passes safe/consistent p
he performance tests show that 3 times as much I/O was used accessing
the btree.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
On Tue, 2008-09-02 at 12:28 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > As discussed on 26 June, "Join Removal/Vertical Partitioning", here's a
> > patch to remove joins in certain circumstances.
>
> Some points not made in the
On Tue, 2008-09-02 at 17:03 +0100, Gregory Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> >> On Mon, 2008-09-01 at 22:23 +0300, Heikki Linnakangas wrote:
> >>> Did plan invalidation make it safe to
On Tue, 2008-09-02 at 12:02 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> >> Oh. How does the query look like after removing the join, then?
>
> > Same answer, just slower. Removing the join makes the access to a into a
> > SeqScan, whereas i
et of FK is not indexed on A
Which doesn't seem that likely to occur.
Thanks both to Heikki and Greg for good, fast input on this patch.
Nothing more needed now while I rework patch.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via
On Tue, 2008-09-02 at 14:20 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > select a.col2
> > from a left outer join b on a.col1 = b.col1
> > where b.col2 = 1;
> >
> > is logically equivalent to
> >
> > select a.col2
> > from a;
>
ner might be able
> to discover that it can find those records quicker by scanning
> customer, finding the matching and then using
> an index to look them up in invoices.
That's a good idea.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
On Tue, 2008-09-02 at 10:41 +0100, Simon Riggs wrote:
> On Mon, 2008-09-01 at 22:23 +0300, Heikki Linnakangas wrote:
> > Couldn't we also do join removal for inner joins, when there's a foreign
> > key reference that enforces that there's one and only one matc
On Tue, 2008-09-02 at 14:03 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Tue, 2008-09-02 at 13:41 +0300, Heikki Linnakangas wrote:
> >> Simon Riggs wrote:
> >>> On Tue, 2008-09-02 at 13:20 +0300, Heikki Linnakangas wrote:
> >>>> Simon
On Tue, 2008-09-02 at 13:41 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Tue, 2008-09-02 at 13:20 +0300, Heikki Linnakangas wrote:
> >> Simon Riggs wrote:
> >>> It turns out that a join like this
> >>>
> >>> select a.
On Tue, 2008-09-02 at 13:20 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > It turns out that a join like this
> >
> > select a.col2
> > from a left outer join b on a.col1 = b.col1
> > where b.col2 = 1;
> >
> > can be cheaper if we don
On Mon, 2008-09-01 at 22:23 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Patch works, but there's a bit I haven't finished yet - checking unique
> > indexes.
>
> Did plan invalidation make it safe to rely on the presence of a unique
> index for pla
On Mon, 2008-09-01 at 12:42 +0900, ITAGAKI Takahiro wrote:
> Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> > 1) A refactoring of calls to Rmgr code from xlog.c, and having isolated
> > the code for rmgrs then to allow rmgr plugins to modify and/or add rmgrs
> > to Post
On Thu, 2008-08-07 at 12:44 +0100, Simon Riggs wrote:
> I would like to propose some changes to the infrastructure for recovery.
> These changes are beneficial in themselves, but also form the basis for
> other work we might later contemplate.
>
> Currently
> * the startu
I haven't done that here).
2) contrib module that contains an example rmgr_hook - actually two
examples in one module
These have both been tested in normal mode, WAL_DEBUG mode and in warm
standby recovery, so not a WIP progress patch.
--
Simon Riggs www.2ndQuadrant.com
PostgreS
but haven't worked out how yet...)
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Index: src/backend/optimizer/path/joinrels.c
===
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/opt
On Wed, 2008-08-06 at 16:37 +0100, Simon Riggs wrote:
> I'll submit the fully working plugin once we've stabilised the API. It's
> designed as a contrib module, so it can go in pgfoundry or contrib.
OK, here's fully working plugin, plus API patch.
I expect to open a
On Sat, 2008-08-02 at 20:12 +0100, Simon Riggs wrote:
> Chris,
>
> Thanks for all of those changes... added as suggested (in next version)
>
> On Wed, 2008-07-30 at 14:58 -0400, chris wrote:
>
> > It's not clear to me that the plugin is actually working.
> &
On Thu, 2008-07-10 at 14:59 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Thu, 2008-06-26 at 12:50 -0400, Tom Lane wrote:
> >> I think you need to move up a level, and perhaps refactor some of the
> >> existing code to make it easier to
hat to give a different answer.
I was going to add an SQL function to estimate the number of tuples in
the same way as the optimizer does. That way we get the same answer from
the EXPLAIN as we would have got on the main server and we don't need to
run select count(*) against each table (unle
igurable delay, which defaults to
the current behaviour, but that can be set to zero (the recommended
way). Which is what the patch implements.
Andrew, Heikki: ISTM its time to just make the changes yourselves. This
is just going round and round to no benefit. This doesn't warrant such a
long
a big problem.
It was discussed and it was Tom's suggestion to do this. I agreed!
> I confess to not having read the patch in detail --- where did the other
> 8 bits go to?
Keeping track of the number of hints set on a block since last write.
--
Simon Riggs www.2ndQuadr
a time to
one output file. We need a way to dump multiple tables concurrently,
ending in multiple files/filesystems.
> Oh and pg_dumpall? It should have been removed right around the release
> of 7.2, pg_dump -A please.
Good idea
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Tr
On Sat, 2008-07-26 at 13:56 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I want to dump tables separately for performance reasons. There are
> > documented tests showing 100% gains using this method. There is no gain
> > adding this to pg_restore
On Sat, 2008-07-26 at 12:20 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2008-07-25 at 19:16 -0400, Tom Lane wrote:
> >> The key problem is that pg_restore is broken:
>
> > The key capability here is being able to split the d
On Fri, 2008-07-25 at 19:16 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > [ pg_dump_beforeafter.v6.patch ]
> Unfortunately there's still a lot of work to do, and I don't feel like
> doing it so I'm bouncing this patch back for furthe
provide more information about optimizer issues
and opportunities.
Comments welcome.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
TOM.tar
Description: Unix tar archive
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make cha
On Fri, 2008-07-25 at 16:58 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2008-07-25 at 16:31 -0400, Tom Lane wrote:
> >> I thought the latest conclusion was that changing the behavior of
> >> pg_standby itself wouldn't addres
On Fri, 2008-07-25 at 16:31 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Tue, 2008-07-22 at 17:19 -0700, Martin Zaun wrote:
> >> reviewing your patch
>
> > Current status is this:
> > * My understanding is that Dave and And
gh about this issue to test a fix, we shouldn't bother.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
On Thu, 2008-07-24 at 03:54 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > [80k patch]
>
> Surely there is a whole lot of unintended noise in this patch?
> I certainly don't believe that you meant to change keywords.c
> for instance.
Rem
On Wed, 2008-07-23 at 21:38 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Tue, 2008-07-22 at 17:19 -0700, Martin Zaun wrote:
> >> 8. Unresolved question of implementing now/later a "cp" replacement
> >
> > The patch implements what's
On Wed, 2008-07-23 at 17:40 +0100, Simon Riggs wrote:
> On Mon, 2008-07-21 at 07:56 -0400, Stephen Frost wrote:
> > Simon,
> >
> > * Simon Riggs ([EMAIL PROTECTED]) wrote:
> > > > I hadn't realized that Simon was using "pre-schema" and "p
On Mon, 2008-07-21 at 07:56 -0400, Stephen Frost wrote:
> Simon,
>
> * Simon Riggs ([EMAIL PROTECTED]) wrote:
> > > I hadn't realized that Simon was using "pre-schema" and "post-schema"
> > > to name the first and third parts. I'd agree
sleeptime = 5; /* amount of time to sleep between file
> checks */
> int holdtime = 0; /* amount of time to wait once file appears
> full */
> int waittime = -1; /* how long we have been waiting, -1 no wait
> * yet *
On Tue, 2008-07-22 at 17:19 -0700, Martin Zaun wrote:
> 1. Issues with applying the patch to CVS HEAD:
Sounds awful. Thanks for the review, will fix.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pg
On Mon, 2008-07-21 at 16:33 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Mon, 2008-07-21 at 11:36 +0530, Pavan Deolasee wrote:
> >> I think we should try at least one or two possible optimizations and
> >> get some numbers before we jum
our mind into a pretzel to wrap it around this
> behavior.
Perhaps my mind was already toroidally challenged? :-}
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
#x27;ll fix the bug, but I'm not doing any more on this now till feature
freeze. It's the wrong time to chase mirages.
Thanks for checking my logic.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgs
On Mon, 2008-07-21 at 07:46 -0400, Stephen Frost wrote:
> * Simon Riggs ([EMAIL PROTECTED]) wrote:
> > The options split the dump into 3 parts that's all: before the load, the
> > load and after the load.
> >
> > --schema-pre-load says
> > "Dumps exac
"pre-data and "post-data"?
OK by me. Any other takers?
I also suggested having three options
--want-pre-schema
--want-data
--want-post-schema
so we could ask for any or all parts in the one dump. --data-only and
--schema-only are negative options so don't allow this.
(I don&#
On Sun, 2008-07-20 at 21:18 -0400, Stephen Frost wrote:
> * Simon Riggs ([EMAIL PROTECTED]) wrote:
> > On Sun, 2008-07-20 at 17:43 -0400, Stephen Frost wrote:
> > > Even this doesn't cover everything though- it's too focused on tables
> > > and data loading
here appears to be a bit of mistakenly included additions. The
> patch to pg_restore.sgml attempts to add in documentation for
> --superuser. I'm guessing that was unintentional, and looks like
> just a mistaken extra copy&paste.
Thanks, will do.
--
Simon Rig
On Sun, 2008-07-20 at 05:47 +0100, Simon Riggs wrote:
> On Sat, 2008-07-19 at 23:07 -0400, Stephen Frost wrote:
> > Simon,
> >
> > I agree with adding these options in general, since I find myself
> > frustrated by having to vi huge dumps to change simple schem
.
>
> Beyond those minor points, the patch looks good to me.
Thanks for the review. I'll make the changes you suggest.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
On Fri, 2008-07-18 at 01:44 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Thu, 2008-07-17 at 17:10 -0400, Alvaro Herrera wrote:
> >> I don't like your wording though; it feels too verbose (and you're
> >> losing the ANALYZE
On Thu, 2008-07-17 at 17:10 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
> >
> > Is autovacuum doing a wraparound-avoiding VACUUM?
> > Currently, no easy way to tell.
> >
> > Patch to change message of autovac in pg_stat_activity when we are
> > perfo
rwise hope it would be.
That way we can tell difference between hung and just important.
Perhaps message should say "non-automatically cancelled VACUUM
", but that sounded more obscure than the phrase I selected.
Discuss...
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Trainin
see a concrete example
will help us test whether we got the API in the right place.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.
On Wed, 2008-07-09 at 21:39 -0400, Greg Smith wrote:
> On Fri, 4 Jul 2008, Simon Riggs wrote:
>
> > No action on this seen since last commitfest, but I think we should
> do
> > something with it, rather than just ignore it.
>
> Just no action worth reporting yet.
On Mon, 2008-07-07 at 16:13 +0100, Simon Riggs wrote:
> I notice log_temp_files is a PGC_USERSET parameter, which is out of step
> with our current thinking on who is allowed to initiate logging.
>
> Is there a rationale for this? Or should we set this to PGC_SUSET like
> all th
settable, with the attached patch.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Index: src/bin/psql/help.c
===
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/bin/psql/help.c,v
retrieving revi
On Sat, 2008-07-05 at 16:00 +0100, Dave Page wrote:
> On Sat, Jul 5, 2008 at 10:41 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> >
> > It can be optional since plugins can add parameters also.
>
> GUCs I assume you mean, not grammar. Unless I'm misreading the code
On Sun, 2008-07-06 at 00:06 +1000, Russell Smith wrote:
> Simon Riggs wrote:
> > Minor patch on pgbench
> >
> > 1. -i option should run vacuum analyze only on pgbench tables, not *all*
> > tables in database.
> >
> How does this work with custom scripts?
I
Minor patch on pgbench
1. -i option should run vacuum analyze only on pgbench tables, not *all*
tables in database.
2. pre-run cleanup step was DELETE FROM HISTORY then VACUUM HISTORY.
This is just a slow version of TRUNCATE HISTORY.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL
help said they were toggles.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Index: src/bin/psql/command.c
===
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/bin/psql/command.c,v
retrieving rev
Fix minor bug in pg_standby, noted by Ferenc Felhoffer
Request immediate apply to CVS HEAD and 8.3
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Index: contrib/pg_standby/pg_standby.c
On Fri, 2008-07-04 at 17:20 +0100, Simon Riggs wrote:
>
Sorry, I noticed a few typos in my sample DTD.
with some additional elements for stats
and the attlist below was for the not element
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Supp
On Fri, 2008-07-04 at 19:38 +0100, Dave Page wrote:
> On Fri, Jul 4, 2008 at 5:20 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> >
> > * If the patch was implemented as an ExplainOneQuery_hook we would be
> > able to use this with 8.3 also, which might be interesting.
On Fri, 2008-07-04 at 12:05 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Anyway, I note that we don't have an easy way of sorting by tablespace,
>
> Say what? tablespace is the first component of relfilenode.
OK, thats a mistake... what
DTD/Schema should only happen when a reasonable range of plans have been
accumulated to allow full understanding of the possibilities
I'm sorry I've found so much to say about this, but don't be dissuaded.
The basic structure of the patch is there, we just need to get the
details ri
ting on the first lock.
Then you should do it with conditional read buffer, so we don't do I/O
if we don't need to.
> > Maybe re-initialising the level value when jumping between pages, so it
> > restarts at level zero. Maybe call them level 1+ so you can spot that
> &g
On Fri, 2008-07-04 at 12:27 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Fri, 2008-06-27 at 19:36 +0300, Heikki Linnakangas wrote:
> >
> >> Here's an updated version of the "relation forks" patch, and an
> >> incremental FSM rewrit
fit at the tablespace
level on a larger server with spread out data whereas on Tom's test
system I would guess just a single tablespace was used.
Anyway, I note that we don't have an easy way of sorting by tablespace,
but I'm sure it would be possible to look up the tablespace for a f
omething up please? And/or post links to the relevant
discussions wherever they took place.
I'm interested in the FSM and how it might change.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-pa
hook to replace ExecutePlan().
> - Move ExecutePlan() to a global function.
The executor_hook.patch is fairly trivial and I see no errors.
The logic of including such a patch is clear. If we have a planner hook
then we should also have an executor hook.
Will you be completing the plug
to a call to a variadic function, if it exists.
e.g. w || x || y || z can be transformed into a call to
concat_variadic(w, x, y, z)
This can then be made to perform better than
concat(concat(concat(w, x), y), z)
which would involve lots of wasted memory copies.
--
Simon Riggs www.2ndQ
On Tue, 2008-07-01 at 13:44 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Patch implements
> >
> > * recommendation to use GnuWin32 cp on Windows
> > * provide "holdtime" delay, default 0 (on all platforms)
> > * default stays same on Wind
>
> >
>
> Yes. Simon has promised a patch to do the above.
Patch implements
* recommendation to use GnuWin32 cp on Windows
* provide "holdtime" delay, default 0 (on all platforms)
* default stays same on Windows="copy" to ensure people upgrading don't
get stung
uum_delay_point())
{
Need to change VacuumCostActive so it is always active during a VACUUM,
so we do accounting even when vacuum wait is zero.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-patches mailing list (pgsql-patches@postg
1 - 100 of 711 matches
Mail list logo
