Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think that's not happening, conditionally or otherwise. The atomicity
>> problems alone are sufficient reason why not, even before you look at
>> the performance issues.
> What are the atomicity problems of adding a create/expire xi
Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > The point I was trying to make was that faster count(*)'s is just a side
> > effect. If we could (conditionally) keep visibility info in indexes,
>
> I think that's not happening, conditionally or otherwise. The atomicity
> problems
Quoth [EMAIL PROTECTED] (Tom Lane):
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> We do have a TODO item:
>> * Consider using MVCC to cache count(*) queries with no WHERE clause
>
>> The idea is to cache a recent count of the table, then have
>> insert/delete add +/- records to the count. A
On 10/4/03 2:00 AM, "Hannu Krosing" <[EMAIL PROTECTED]> wrote:
>
> If the WHERE clause could use the same index (or any index with
> visibility info) then there would be no need for "walking through the
> tuples" in data relation.
>
> the typical usecase cited on [HACKERS] was time series data, w
Hannu Krosing <[EMAIL PROTECTED]> writes:
> The point I was trying to make was that faster count(*)'s is just a side
> effect. If we could (conditionally) keep visibility info in indexes,
I think that's not happening, conditionally or otherwise. The atomicity
problems alone are sufficient reason
Tom Lane kirjutas L, 04.10.2003 kell 19:07:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Christopher Browne kirjutas R, 03.10.2003 kell 00:57:
> >> A while back I outlined how this would have to be done, and for it to
> >> be done efficiently, it would be anything BUT simple.
>
> > Could this
Bruce Momjian <[EMAIL PROTECTED]> writes:
> It doesn't seem complex enough for a separate TODO.detail item.
I thought it was, if only because it is so easy to think of wrong
implementations.
regards, tom lane
---(end of broadcast)--
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> ... and it would give the wrong answers. Unless the cache is somehow
> >> snapshot-aware, so that it can know which other transactions should be
> >> included in your count.
>
> > The cache is an ordinary table,
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ... and it would give the wrong answers. Unless the cache is somehow
>> snapshot-aware, so that it can know which other transactions should be
>> included in your count.
> The cache is an ordinary table, with xid's on every row. I me
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > We do have a TODO item:
> > * Consider using MVCC to cache count(*) queries with no WHERE clause
>
> > The idea is to cache a recent count of the table, then have
> > insert/delete add +/- records to the count. A COUNT(*) would g
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We do have a TODO item:
> * Consider using MVCC to cache count(*) queries with no WHERE clause
> The idea is to cache a recent count of the table, then have
> insert/delete add +/- records to the count. A COUNT(*) would get the
> main cached recor
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Christopher Browne kirjutas R, 03.10.2003 kell 00:57:
>> A while back I outlined how this would have to be done, and for it to
>> be done efficiently, it would be anything BUT simple.
> Could this be made a TODO item, perhaps with your attack plan.
I
Christopher Browne wrote:
> [EMAIL PROTECTED] (Jean-Luc Lachance) writes:
> > That's one of the draw back of MVCC.
> > I once suggested that the transaction number and other house keeping
> > info be included in the index, but was told to forget it...
> > It would solve once and for all the issue
On Sat, Oct 04, 2003 at 12:29:55AM +0100, Matt Clark wrote:
> My real world experience on a *very* heavily updated OLTP type DB, following
> advice from this list (thanks guys!), is that there is essentially zero cost
> to going ahead and vacuuming as often as you feel like it. Go crazy, and
> spe
On Fri, Oct 03, 2003 at 11:49:03PM -0400, Tom Lane wrote:
>
> What if said SELECTs are using the index in question?
That's a good reason to build a new index and, when it's done, drop
the old one. It still prevents writes, of course.
A
--
Andrew Sullivan 204-4141
On Fri, Oct 03, 2003 at 02:24:42PM -0600, Rob Nagler wrote:
> I've read some posts that says vacuum doesn't lock, but my experience
> today indicates the opposite. It seemed that "vacuum full analyze"
VACUUM doesn't. VACUUM FULL does.
--
Andrew Sullivan 204-4141 Yo
On Fri, 3 Oct 2003, Bruce Momjian wrote:
>
> I have updated the FAQ to be:
>
> In comparison to MySQL or leaner database systems, we are
> faster for multiple users, complex queries, and a read/write query
> load. MySQL is faster for SELECT queries done by a few users.
>
> Is th
On our message boards each post is a row. The powers that be like to know
how many posts there are total (In addition to 'today')-
select count(*) from posts is how it has been
done on our informix db. With our port to PG I instead select reltuples
pg_class.
We have exactly the same situation, e
Christopher Browne kirjutas R, 03.10.2003 kell 00:57:
> [EMAIL PROTECTED] (Jean-Luc Lachance) writes:
> > That's one of the draw back of MVCC.
> > I once suggested that the transaction number and other house keeping
> > info be included in the index, but was told to forget it...
> > It would solv
19 matches
Mail list logo
