> On Mon, 2005-01-17 at 18:43 -0500, Tom Lane wrote:
>> I have already
>> suggested to core that we should insist on 8.1 not requiring an initdb,
>> so as to ensure that people will migrate up to it easily from 8.0.
> So is it firm policy that changes that require a catversion update
> cannot be m
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> If the patch is ready to be committed early in the cycle, I'd say most
> definitely ... just depends on how late in the cycle its ready ...
My recollection is that it's quite far from being complete. I had hoped
to spend some time during the 8.1 c
On Wed, 2005-01-19 at 19:14 +0100, Yann Michel wrote:
> The effect while using a seperate buffer cache for different objects,
> i.e. using a lru list would stay the same. There would be "only" two
> more than one buffer cache for a certain object gourp or class.
Multiple buffer caches and pinning
To fill in some details I think what he's saying is this:
=> create table foo(...);
=> create table foo_count(num int);
=> insert into foo_count values(0);
=> create table foo_change(num int);
then create a trigger "after delete on foo" that does "insert into
foo_change values(-1)" and a trigger
If the patch is ready to be committed early in the cycle, I'd say most
definitely ... just depends on how late in the cycle its ready ...
I *believe* that 8.1, we're looking at a 2mo cycle before beta, so figure
beta for ~April 1st (no april fools jokes, eh?) ...
On Wed, 19 Jan 2005, Heikki Lin
On Wed, Jan 19, 2005 at 10:16:38AM -0600, Bruno Wolff III wrote:
> On Wed, Jan 19, 2005 at 14:59:17 -,
> Mark Cave-Ayland <[EMAIL PROTECTED]> wrote:
>
> > So then I would use SELECT COUNT(*) FROM person_count whenever I wanted to
> > know the current number of person records. How much quicker
Hi,
Now that we got 8.0 out of the door, I'm submitting my two-phase commit patch
again for discussion.
http://www.hut.fi/~hlinnaka/pgsql/
Do we want it in 8.1, if we want a short development cycle? It needs a new
pg_twophase subdirectory, and it introduces a new system view, so I guess it
requ
Hi,
On Wed, Jan 19, 2005 at 11:54:50AM -0600, Bruno Wolff III wrote:
>
> > objects will use the default one. I think even count(*) queries could
> > benefit from this buffer-splitting due to indexes might be pinned to
> > this buffer pool.
>
> This wouldn't have any special effect on count(*) q
[Sorry, Neil, for abusing your thread. Moving this discussion back to
where it belongs.]
On Tue, 18 Jan 2005 13:17:17 -0300, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
>Hmm. I think this is a good idea on principle, but what happens in case
>a previous vacuum was interrupted? Is there a possibil
Tom Lane wrote:
> Bruce Momjian writes:
> > In working with someone who had ext3 file system corruption, I found the
> > need for this capability I have added to the TODO list:
>
> > * Add 'tid != tid ' operator for use in corruption recovery
>
> WHERE NOT (tid = tid) ?
Oh, that works? Int
Bruce Momjian writes:
> In working with someone who had ext3 file system corruption, I found the
> need for this capability I have added to the TODO list:
> * Add 'tid != tid ' operator for use in corruption recovery
WHERE NOT (tid = tid) ?
regards, tom lane
-
On Wed, Jan 19, 2005 at 17:44:00 +0100,
Yann Michel <[EMAIL PROTECTED]> wrote:
>
> as there were several questions about increasing performance in dwh
> systems I was looking for some hints about how to "pin" an object to the
> buffer so that they are not aged out due to the space is needed by a
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
So is it firm policy that changes that require a catversion update
cannot be made during the 8.1 cycle?
Not yet --- I suggested it but didn't get any yeas or nays. I don't
feel this is solely core's decision anyway ... what do the ass
Hi,
as there were several questions about increasing performance in dwh
systems I was looking for some hints about how to "pin" an object to the
buffer so that they are not aged out due to the space is needed by any
other process or object. I know that in oracle you can do this by
defining a seper
On Wed, Jan 19, 2005 at 14:59:17 -,
Mark Cave-Ayland <[EMAIL PROTECTED]> wrote:
> BEGIN;
> INSERT INTO person (first_name, Tel) VALUES ('Fred',
> '12345');
> INSERT INTO person_count(id) VALUES (currval('id_seq'));
> COMMIT;
>
>
> So then I would use SELECT
On Jan 19, 2005, at 4:54 AM, Zeugswetter Andreas DAZ SD wrote:
Another algorithm that was written by
university folk (thus probably not patent prone) that looks promising
is:
http://www.cs.wm.edu/hpcs/WWW/HTML/publications/papers/TR-02-6.pdf
http://parapet.ee.princeton.edu/~sigm2002/papers/p31-ji
> Date: Wed, 12 Jan 2005 18:45:09 -0800
> From: Jeff Davis <[EMAIL PROTECTED]>
> To: Alvaro Herrera <[EMAIL PROTECTED]>
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: Much Ado About COUNT(*)
> Message-ID: <[EMAIL PROTECTED]>
(cut)
> Thanks for the link. It looks like it breaks it up into chunk
In working with someone who had ext3 file system corruption, I found the
need for this capability I have added to the TODO list:
* Add 'tid != tid ' operator for use in corruption recovery
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > So is it firm policy that changes that require a catversion update
> > cannot be made during the 8.1 cycle?
>
> Not yet --- I suggested it but didn't get any yeas or nays. I don't
> feel this is solely core's deci
On Wed, 19 Jan 2005 10:53:14 +0100
"Magnus Hagander" <[EMAIL PROTECTED]> wrote:
> An idea around this would be to plan never to release 8.1. Instead,
> direct HEAD towards 8.2 with a normal dev cycle (or rather, let's aim
> for a short one, but in reality short may not be all that short..).
> Then
Tom Lane wrote:
What this really boils down to is whether we think we have
order-of-a-year before the patent is issued. I'm nervous about
assuming that. I'd like to have a plan that will produce a tested,
credible patch in less than six months.
Why not having a beta on an 8.0.x version if ARC rep
> > There's a very recent paper at
> > http://carmen.cs.uiuc.edu/~zchen9/paper/TPDS-final.ps on an alternative
> > to ARC which claims superior performance ...
>
> From a quick glance, this doesn't look applicable. The authors are
> discussing buffer replacement strategies for a multi-level cac
> > On Mon, 2005-01-17 at 18:43 -0500, Tom Lane wrote:
> >> I have already
> >> suggested to core that we should insist on 8.1 not requiring an
> >> initdb, so as to ensure that people will migrate up to it
> easily from 8.0.
>
> > So is it firm policy that changes that require a catversion upda
On Wed, 2005-01-19 at 16:25 +1100, Neil Conway wrote:
> On Tue, 2005-01-18 at 23:26 -0500, Tom Lane wrote:
> > Not yet --- I suggested it but didn't get any yeas or nays. I don't
> > feel this is solely core's decision anyway ... what do the assembled
> > hackers think?
>
> I'm not sure it's a gr
24 matches
Mail list logo
