Sometime last year, a discussion started about including visibility
metadata to avoid heap fetches during an index scan:
http://archives.postgresql.org/pgsql-patches/2007-10/msg00166.php
http://archives.postgresql.org/pgsql-patches/2008-01/msg00049.php
I think the last discussion on this was in
"Karl Schnaitter" <[EMAIL PROTECTED]> writes:
"Karl Schnaitter" <[EMAIL PROTECTED]> writes:
> (1) & (4) require an UPDATE or DELETE to twiddle the old index tuple. Tom has
> noted (in the linked message) that this is not reliable if the index has any
> expression-valued columns, because it is not
Attached is a worked-out patch for the approach proposed here:
http://archives.postgresql.org/pgsql-hackers/2008-06/msg00777.php
namely, that cache management for de-TOASTed datums is handled
by TupleTableSlots.
To avoid premature detoasting of values that we might never need, the
patch introduces
Gregory Stark wrote:
(1) & (4) require an UPDATE or DELETE to twiddle the old index tuple. Tom has
noted (in the linked message) that this is not reliable if the index has any
expression-valued columns, because it is not always possible to find the old
index entry. For this reason, the proposed p
On Friday 27 June 2008 12:58:41 Richard Huxton wrote:
> Richard Huxton wrote:
> > Richard Huxton wrote:
> >> At present it means you can't reliably do:
> >> DROP DATABASE foo;
> >> pg_restore --create foo.dump
> >> I'd then have to either hand edit the dumpall dump or wade through a
> >> bunch of
Robert Treat wrote:
> On Friday 27 June 2008 12:58:41 Richard Huxton wrote:
> > > Am I doing something stupid here?
> >
> > OK - so to get the ALTER DATABASE commands I need to dump the schema for
> > the entire cluster. Is that really desired behaviour?
>
> Certainly not desired by a number of p
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Robert Treat wrote:
>> Certainly not desired by a number of people I have talked to, but I don't
>> have
>> much hope in seeing the behavoir change... perhaps someday if we get around
>> to merging pg_dump and pg_dumpall
> I have never heard anyo
[ after recovering from choking... ]
Tom "spot" Callaway presents a vivid new image in this line:
> What you're doing is analogous to using a loaded shotgun as a golf club,
> and what you're suggesting is that we take the safety off, because it
> interferes with your golf game.
https://www.redha
On Fri, 2008-06-27 at 18:00 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > In cases where we know we will assign a real xid, can we just skip the
> > assignment of the virtual xid completely?
>
> Even if we could do this I doubt it would be a good idea. It'd destroy
> the i
On Fri, 2008-06-27 at 17:44 +0200, Florian G. Pflug wrote:
> Simon Riggs wrote:
> > When we move from having a virtual xid to having a real xid I don't
> > see any attempt to re-arrange the lock queues. Surely if there are
> > people waiting on the virtual xid, they must be moved across to wait
>
On Fri, 2008-06-27 at 17:50 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Thu, 2008-06-26 at 13:42 -0400, Tom Lane wrote:
> >> It might be possible to treat "ignore the RHS" as a join strategy and
> >> try to apply it while forming join relations, which would be late enou
11 matches
Mail list logo
