Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> So instead of pressing to try to get something into 8.3, I would rather
> >> we stand back and think about it some more.
>
> > I understand why you are saying hold for 8.4, but this issue came up in
> > the middle
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> So instead of pressing to try to get something into 8.3, I would rather
>> we stand back and think about it some more.
> I understand why you are saying hold for 8.4, but this issue came up in
> the middle of the 8.3 development cycle
Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > Alvaro Herrera wrote:
> >> At this
> >> point I feel like the patch still needs some work and reshuffling before
> >> it is in an acceptable state. The fact that there are some API changes
> >> for which the patch needs to be adj
On Tue, 7 Aug 2007, Decibel! wrote:
> ISTM that having a built-in array_to_set function would be awfully
> useful... Is the aggregate method below an acceptable way to do it?
Umm, the array_to_set function is not an aggregate. Personally, when I
need this functionality, I use this function conve
On Tue, Aug 07, 2007 at 06:46:05PM -0400, Tom Lane wrote:
> I'm tempted to stop accepting connections once we start the shutdown
> checkpoint (ie, tell the bgwriter to shut down). This would at least
> limit the width of the window in which incoming connections get ignored.
> We could also close t
On 8/7/07, Bertram Scharpf <[EMAIL PROTECTED]> wrote:
> accept 76AC-752C-3D91
>
cool, good for you
--
Atentamente,
Jaime Casanova
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better
On 8/8/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> On 8/7/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> > I ran some CPU intensive pgbench tests on HOT. Results are not
> > surprising, HOT makes practically no difference on the total transaction
> > rate, but reduces the need to vacuum:
>
Hi,
I happened to feel need for something like Oracle's
connect-by mechanism. In the contribs I found Joe Conways
`tablefunc' but I missed some features there. So I had a
look at the source code.
First of all thanks a lot to Joe, I learned much of your
code. Anyway, when I added the features I d
On Tue, 7 Aug 2007, Decibel! wrote:
Is logging really the answer for that? ISTM it'd be better to provide
statistics info so that you could monitor autovacuum activity with
things like cricket, SNMP, etc.
There are two sides to this. One is that it's difficult to right now to
tell when your
ISTM that having a built-in array_to_set function would be awfully
useful... Is the aggregate method below an acceptable way to do it?
- Forwarded message from Merlin Moncure <[EMAIL PROTECTED]> -
On 8/3/07, Guy Fraser <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-08-01 at 07:14 +0530, Merlin
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> 4. Keep spawning a child, but mark it in the BackendList as known
>> doomed, and don't count such children when deciding if it's OK to
>> terminate. The problem with this idea is that such children will
>> still
On Tue, 2007-08-07 at 16:52 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Tue, 2007-08-07 at 15:14 -0400, Tom Lane wrote:
> >> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >>> We also need something that will re-zero the stats when they reach
> >>> anywhere near integer o
accept 76AC-752C-3D91
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Decibel! wrote:
> On Tue, Aug 07, 2007 at 11:59:03AM -0700, Andrew Hammond wrote:
>> On 8/7/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> Peter Eisentraut <[EMAIL PROTECTED]> writes:
But INFO is not shown by default.
>>> INFO is mostly a hack to try
On Tue, Aug 07, 2007 at 11:59:03AM -0700, Andrew Hammond wrote:
> On 8/7/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> >
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > But INFO is not shown by default.
> >
> > INFO is mostly a hack to try to emulate VACUUM VERBOSE's ancient
> > behavior before
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> How hard will it be to add the infrastructure to allow new index types
> to be added to the server dynamically?
INSERT INTO pg_am VALUES (...);
I don't really think we need more than that, at least not till non-core
index AMs are a whole lot thicker on
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> 2. Pointer swinging. At the moment, after a row is HOT updated, the only
> way to get rid of the redirecting line pointer is to run VACUUM FULL or
> CLUSTER (or delete or cold update the row and vacuum). If we want to
> implement pointer swinging
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Tue, 2007-08-07 at 15:14 -0400, Tom Lane wrote:
>> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>>> We also need something that will re-zero the stats when they reach
>>> anywhere near integer overflow, since we must not allow them to wrap. I
>>> would su
On Aug 7, 1:26 pm, Arthernan <[EMAIL PROTECTED]> wrote:
> I want to learn how a real database works. And I am about to
> start reading the Postgre source code.
> Are there any online documents that may document the code? Even
> if it was a general guideline.
> Any information
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Riggs wrote:
> On Thu, 2007-08-02 at 16:12 -0400, Tom Lane wrote:
> Heck, I'd much rather have bitmap and/or GIT than hash indexes any day.
But hash is all about the equality man!
- --
=== The PostgreSQL Company: Command Prompt, Inc.
On Thu, 2007-08-02 at 16:12 -0400, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > Alvaro Herrera wrote:
> >> At this
> >> point I feel like the patch still needs some work and reshuffling before
> >> it is in an acceptable state. The fact that there are some API changes
> >>
Heikki Linnakangas wrote:
> Stefan Kaltenbrunner wrote:
>> Heikki Linnakangas wrote:
>>> There's three things clearly missing in the patch:
>>>
>>> 1. HOT updates on tables with expression or partial indexes. Hasn't been
>>> done yet because it should be pretty straightforward and we've had more
>>
Stefan Kaltenbrunner wrote:
Heikki Linnakangas wrote:
2. Pointer swinging. At the moment, after a row is HOT updated, the only
way to get rid of the redirecting line pointer is to run VACUUM FULL or
CLUSTER (or delete or cold update the row and vacuum). If we want to
implement pointer swingin
On Tue, 2007-08-07 at 20:27 +0100, Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > On Tue, 2007-08-07 at 13:16 +0100, Heikki Linnakangas wrote:
> >> I ran some CPU intensive pgbench tests on HOT. Results are not
> >> surprising, HOT makes practically no difference on the tot
On Tue, 2007-08-07 at 15:14 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > We also need something that will re-zero the stats when they reach
> > anywhere near integer overflow, since we must not allow them to wrap. I
> > would suggest we simply reset all values to zero for
On 8/7/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> I ran some CPU intensive pgbench tests on HOT. Results are not
> surprising, HOT makes practically no difference on the total transaction
> rate, but reduces the need to vacuum:
>
> unpatched HOT
> tps 3680
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Tue, 2007-08-07 at 13:16 +0100, Heikki Linnakangas wrote:
>> I ran some CPU intensive pgbench tests on HOT. Results are not
>> surprising, HOT makes practically no difference on the total transaction
>> rate, but reduces the need to vacuum:
>> ...
> N
On Tue, 2007-08-07 at 13:16 +0100, Heikki Linnakangas wrote:
> I ran some CPU intensive pgbench tests on HOT. Results are not
> surprising, HOT makes practically no difference on the total transaction
> rate, but reduces the need to vacuum:
>
> unpatched HOT
> tps
Stefan Kaltenbrunner wrote:
> Heikki Linnakangas wrote:
>> There's three things clearly missing in the patch:
>>
>> 1. HOT updates on tables with expression or partial indexes. Hasn't been
>> done yet because it should be pretty straightforward and we've had more
>> important things to do. Though n
On Aug 7, 1:26 pm, Arthernan <[EMAIL PROTECTED]> wrote:
> I want to learn how a real database works. And I am about to
> start reading the Postgre source code.
>
> Are there any online documents that may document the code? Even
> if it was a general guideline.
>
> Any information
On Tue, 2007-08-07 at 15:40 +0100, Heikki Linnakangas wrote:
> Tom Lane wrote:
> > Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> >>unpatched HOT
> >> autovacuums116 43
> >> autoanalyzes 139 60
> >
> >> HOT greatly reduces the number o
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> We also need something that will re-zero the stats when they reach
> anywhere near integer overflow, since we must not allow them to wrap. I
> would suggest we simply reset all values to zero for that table.
pgstat counters are int64.
"Tom Lane" <[EMAIL PROTECTED]> writes:
> 4. Keep spawning a child, but mark it in the BackendList as known
> doomed, and don't count such children when deciding if it's OK to
> terminate. The problem with this idea is that such children will
> still be connected to shared memory, and we really do
On Tue, 2007-08-07 at 19:01 +0100, Heikki Linnakangas wrote:
> There's three things clearly missing in the patch:
>
> 1. HOT updates on tables with expression or partial indexes. Hasn't been
> done yet because it should be pretty straightforward and we've had more
> important things to do. Though
On 8/7/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > But INFO is not shown by default.
>
> INFO is mostly a hack to try to emulate VACUUM VERBOSE's ancient
> behavior before we redesigned the elog levels. It's intended for
> controlling messages that
I want to learn how a real database works. And I am about to
start reading the Postgre source code.
Are there any online documents that may document the code? Even
if it was a general guideline.
Any information will be greatly appreciated.
Arturo Hernandez
--
Heikki Linnakangas wrote:
> There's three things clearly missing in the patch:
>
> 1. HOT updates on tables with expression or partial indexes. Hasn't been
> done yet because it should be pretty straightforward and we've had more
> important things to do. Though not critical, should be finished be
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> But INFO is not shown by default.
INFO is mostly a hack to try to emulate VACUUM VERBOSE's ancient
behavior before we redesigned the elog levels. It's intended for
controlling messages that should go to a client because the client
asked for them, and
[ redirected to -hackers for discussion of bug fix ]
"Keaton Adams" <[EMAIL PROTECTED]> writes:
> Some additional information I just received from one of the operations
> personnel:
> 1. I set pg_database.datallowconn to true on template0 in an attempt to
> log into the database with psql and per
There's three things clearly missing in the patch:
1. HOT updates on tables with expression or partial indexes. Hasn't been
done yet because it should be pretty straightforward and we've had more
important things to do. Though not critical, should be finished before
release in my opinion.
2. Poin
On 8/2/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
>
>
>
>
> . It would also be better if we didn't emit a
> > separate WAL record for defraging a page, if we also prune it at the
> > same time. I'm not that worried about WAL usage in general, but that
> > seems simple enough to fix.
>
>
>
> Ah I
On Tue, Aug 07, 2007 at 06:53:48PM +0100, Simon Riggs wrote:
> On Tue, 2007-08-07 at 18:25 +0530, Pavan Deolasee wrote:
>
> > I am posting the version 13 of HOT patch on pgsql-patches. It
> > includes the changes based on feedback received on version 11.
>
> I think we need a change log, so we ca
On Tue, 2007-08-07 at 18:25 +0530, Pavan Deolasee wrote:
> I am posting the version 13 of HOT patch on pgsql-patches. It
> includes the changes based on feedback received on version 11.
I think we need a change log, so we can see which feedback has resulted
in changes and which has not. Otherwise
On Mon, Aug 06, 2007 at 03:55:14PM -0400, Robert Treat wrote:
> On Saturday 04 August 2007 09:45, Magnus Hagander wrote:
> > Rohit Khare wrote:
> > > Seeing the history of PostgreSQL development, following features are
> > > expected in pgAdmin:
> > >
> > > (1) Facility to insert a column in betwee
Tom Lane wrote:
> > Yes, by default or at least at no level higher than INFO.
>
> No, NOT by default. Our users have made it perfectly clear that they
> don't want the logs cluttered with high-volume information about
> non-error normal workings of the system. Every time we have caused
> the syst
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> With 8.3 having autovacuum on by default, we really should be logging at
> a mininum:
> autovacuum start
> autovacuum working (what am I working on but not what I am doing,
> meaning we don't need tuple information etc..)
> autovacuum stop
> Yes, by
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
HOT greatly reduces the number of vacuums needed. That's good, that's
where the gains in throughput in longer I/O bound runs comes from.
But surely failing to auto-analyze after a HOT update
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dimitri Fontaine wrote:
> Le mardi 07 août 2007, Tom Lane a écrit :
>> Gregory Stark <[EMAIL PROTECTED]> writes:
>>> log_autovacuum_jobs - output every time a vacuum or analyze *starts*
> [...]
>>> I would also suggest raising the level of the DEBUG2 m
> > unpatched HOT
> > autovacuums 116 43
> > autoanalyzes139 60
>
> > HOT greatly reduces the number of vacuums needed. That's
> good, that's
> > where the gains in throughput in longer I/O bound runs comes from.
>
> But surely failing to
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> I would also suggest raising the level of the DEBUG2 message indicating why
>> tables were chosen or not. At least to DEBUG1 if not to INFO.
>
> It's not acceptable for autovacuum to be cluttering the log by def
Le mardi 07 août 2007, Tom Lane a écrit :
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > log_autovacuum_jobs - output every time a vacuum or analyze *starts*
[...]
> > I would also suggest raising the level of the DEBUG2 message indicating
> > why tables were chosen or not. At least to DEBUG1 if n
Gregory Stark wrote:
I'm having trouble following what's going on with autovacuum and I'm finding
the existing logging insufficient. In particular that it's only logging vacuum
runs *after* the vacuum finishes makes it hard to see what vacuums are running
at any given time. Also, I want to see wh
Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> unpatched HOT
>> autovacuums 116 43
>> autoanalyzes 139 60
>
>> HOT greatly reduces the number of vacuums needed. That's good, that's
>> where the gains in throughput in longer I/O
Gregory Stark <[EMAIL PROTECTED]> writes:
> I would also suggest raising the level of the DEBUG2 message indicating why
> tables were chosen or not. At least to DEBUG1 if not to INFO.
It's not acceptable for autovacuum to be cluttering the log by default.
regards, tom lane
I'm having trouble following what's going on with autovacuum and I'm finding
the existing logging insufficient. In particular that it's only logging vacuum
runs *after* the vacuum finishes makes it hard to see what vacuums are running
at any given time. Also, I want to see what is making autovacuu
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> unpatched HOT
> autovacuums 116 43
> autoanalyzes 139 60
> HOT greatly reduces the number of vacuums needed. That's good, that's
> where the gains in throughput in longer I/O bound runs comes from.
I am posting the version 13 of HOT patch on pgsql-patches. It
includes the changes based on feedback received on version 11.
There is also a bug fix in crash recovery of hard chain
pruning during VACUUM FULL.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
I ran some CPU intensive pgbench tests on HOT. Results are not
surprising, HOT makes practically no difference on the total transaction
rate, but reduces the need to vacuum:
unpatched HOT
tps 36803790
WAL written(MB) 53864804
checkpoin
58 matches
Mail list logo
