Jim,
On 6/26/06 8:15 PM, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> On a somewhat related note, I think that it would be advantageous if the
> FSM had a means to prefer certain pages for a given tuple over other
> pages. This would allow for a better way to keep heap and possibly index
> data mo
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On a loosely related matter, how about changing pg_class.relpages to
> pg_class.reldensity?
IIRC, I considered this earlier, and rejected it because it doesn't cope
well with the corner case relpages == 0. Also, it'll break existing
clients that expect
Alvaro Herrera wrote:
> Clamp last_anl_tuples to n_live_tuples, in case we vacuum a table without
> analyzing, so that future analyze threshold calculations don't get confused.
> Also, make sure we correctly track the decrease of live tuples cause by
> deletes.
Now that the values of n_live_tuple
Tom Lane wrote:
> [EMAIL PROTECTED] (Bruce Momjian) writes:
> > Disallow changing/dropping default expression of a SERIAL column
>
> Wasn't this patch rejected? Your summary is utterly wrong about what
> it does, which makes me wonder whether you reviewed it at all. One
> would also think that a
If you want to merge those functions, please do it as a separate patch
now that the patch has been applied. Having too much unrelated stuff in
a patch does confuse things.
---
Greg Stark wrote:
>
> Currently analyze.c and
It looks like we still don't have any docs for GIN in the tree so I
don't know if those timings are expected or not ...
Ummm my bad. Sorry...
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
On Sun, Jun 25, 2006 at 08:04:18PM -0400, Luke Lonergan wrote:
> Other DBMS have index organized tables that can use either hash or btree
> organizations, both of which have their uses. We are planning to
> implement btree organized tables sometime - anyone else interested in
> this idea?
I'm cur
Jim C. Nasby wrote:
> On Mon, Jun 26, 2006 at 02:32:59PM -0400, Bruce Momjian wrote:
> >
> > It is certainly possible to do what you are suggesting, that is have two
> > index entries point to same chain head, and have the index access
> > routines figure out if the index qualifications still hold
On Mon, Jun 26, 2006 at 02:32:59PM -0400, Bruce Momjian wrote:
>
> It is certainly possible to do what you are suggesting, that is have two
> index entries point to same chain head, and have the index access
> routines figure out if the index qualifications still hold, but that
> seems like a lot
On Mon, 2006-06-26 at 16:54 -0400, Alvaro Herrera wrote:
> > > Another optimization: if we are sure that unfreezing works, we can
> even
> > > mark a table as frozen in a postmaster environment, as long as we
> take
> > > an ExclusiveLock on the table. Thus we know that the vacuum is
> the sole
>
gin uses maintenance_work_mem,so try to increase it and see dramatic
improvements
Oleg
On Mon, 26 Jun 2006, Stefan Kaltenbrunner wrote:
on IRC somebody mentioned that it took >34h to greate a GIN index (on a
tsvector) on a ~3 Million column table (wikipedia dump) with a
reasonable speced box (A
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > What I'm after is not freezing for read-only media, nor archive, nor
> > read-only tables. What I'm after is removing the requirement that all
> > databases must be vacuumed wholly every 2 billion transactions.
>
> Well, if that's t
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What I'm after is not freezing for read-only media, nor archive, nor
> read-only tables. What I'm after is removing the requirement that all
> databases must be vacuumed wholly every 2 billion transactions.
Well, if that's the only goal then I hardly t
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2006-06-26 at 16:43 -0400, Tom Lane wrote:
>> analyze.c (tuples collected in-memory for stats analysis)
> Do we save enough there for us to care?
Possibly not --- it's certainly low-priority, but I listed it for
completeness.
elein <[EMAIL PROTECTED]> writes:
> People will turn around and immediately as for create table like without us
> making the assumptions it wanted all of the extras that come with inheritance.
> COPY is a copy of the table, not additional functionality. The added
> flexibility
> of adding only w
On Mon, 2006-06-26 at 16:43 -0400, Tom Lane wrote:
> I wrote:
> > There isn't any benefit except where we collect lots of tuples, which is
> > to say tuplesort/tuplestore/tuplehashtable. In other places in the
> > executor, there's basically only one transient tuple in existence per
> > plan node;
Simon Riggs wrote:
> On Mon, 2006-06-26 at 13:58 -0400, Alvaro Herrera wrote:
> > The relminxid Patch
> > ===
> >
> > What I'm after is not freezing for read-only media, nor archive, nor
> > read-only tables.
>
> OK, but I am... but I'm happy to not to confuse the discussion.
O
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Does this complete this TODO item?
> o Allow UPDATE tab SET ROW (col, ...) = (...) for updating multiple
> columns
No, that's unrelated.
regards, tom lane
---(end of broadcast)--
I wrote:
> There isn't any benefit except where we collect lots of tuples, which is
> to say tuplesort/tuplestore/tuplehashtable. In other places in the
> executor, there's basically only one transient tuple in existence per
> plan node; jumping through hoops to save 16 bytes per plan node is just
On Mon, Jun 26, 2006 at 12:31:24PM -0400, Greg Stark wrote:
>
> Currently analyze.c and tablecmds.c both have some very similar code to handle
> copying columns from "parent" tables. As long as they were just copying
> columns and in the case of tablecmds.c copying check constraints that wasn't
>
On Mon, 2006-06-26 at 13:58 -0400, Alvaro Herrera wrote:
> Ok, let's step back to discuss this again. Sorry for the length -- this
> is a description of the problem I'm trying to solve, the issues I found,
> and how I tried to solve them.
Thanks. This is good.
> The relminxid Patch
> ===
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2006-06-26 at 14:36 -0400, Tom Lane wrote:
>> I thought for awhile about MemoryTuple (as contrasted to HeapTuple) but
>> that seems too generic. Any other thoughts?
> I like MemoryTuple but since we only use it when we go to disk...
> ExecutorTup
Does this complete this TODO item?
o Allow UPDATE tab SET ROW (col, ...) = (...) for updating multiple
columns
---
Tom Lane wrote:
> Log Message:
> ---
> Change the row constructor syntax (ROW(...
[Resending: apparently the previous one to the list was eaten by spam
filters or something. Changing SMTP relay again ... ]
Ok, let's step back to discuss this again. Sorry for the length -- this
is a description of the problem I'm trying to solve, the issues I found,
and how I tried to solve t
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Oh, good point. Do we remove stats_command_string?
>
> You mean, remove the option to turn it off? I don't think so. Aside
> from whatever remaining overhead there is, there's a possible security
> argument to be made that one migh
On Mon, 2006-06-26 at 14:36 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Mon, 2006-06-26 at 16:48 +0200, Martijn van Oosterhout wrote:
> >> Anyway, I think it's a good idea. Most places in the backend after the
> >> SeqScan/IndexScan node really don't care about most of t
Zeugswetter Andreas DCP SD wrote:
>
> > > head of the chain yet. With an index scan, finding the head is
> easy,
> > > but for a sequential scan, it seems more difficult, and we don't
> have
> > > any free space in the tail of the chain to maintain a pointer to the
> head.
> >
> > Thinking som
I ran your test with all defaults in 8.1 and CVS HEAD on a BSD/OS dual
Xeon and got:
8.1.X 1.946
HEAD1.986
I ran the test ten times on three runs and took the middle value.
It is a slowdown of 2%. I used these configure options:
configure \
--with
on IRC somebody mentioned that it took >34h to greate a GIN index (on a
tsvector) on a ~3 Million column table (wikipedia dump) with a
reasonable speced box (AMD 3400+).
After getting hold of a dump of said table (around 4,1GB in size) I
managed to get the following timings:
test=# CREATE INDEX id
On Fri, Jun 23, 2006 at 06:37:01AM -0400, Mark Woodward wrote:
> While we all know session data is, at best, ephemeral, people still want
> some sort of persistence, thus, you need a database. For mcache I have a
> couple plugins that have a wide range of opitions, from read/write at
> startup and
Currently analyze.c and tablecmds.c both have some very similar code to handle
copying columns from "parent" tables. As long as they were just copying
columns and in the case of tablecmds.c copying check constraints that wasn't
really that bad an idea, the code is pretty simple.
However with part
Dave, all,
> Ahh, you miss the point though - they vanish back into the woodwork when
> they realise that they can't brag that they host the entire project.
> It's not that they want to help, they just want maximum publicity off
> our name for as little hardware as possible.
I seem to have missed
It is certainly possible to do what you are suggesting, that is have two
index entries point to same chain head, and have the index access
routines figure out if the index qualifications still hold, but that
seems like a lot of overhead.
Also, once there is only one visible row in the chain, remo
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2006-06-26 at 16:48 +0200, Martijn van Oosterhout wrote:
>> Anyway, I think it's a good idea. Most places in the backend after the
>> SeqScan/IndexScan node really don't care about most of the header
>> fields and being able to drop them would be ni
On Mon, 2006-06-26 at 16:48 +0200, Martijn van Oosterhout wrote:
> On Mon, Jun 26, 2006 at 10:36:00AM -0400, Tom Lane wrote:
> > While looking at the recently-noticed problem that HashAggregate nodes
> > store more columns of the input than they need to, I couldn't help
> > noticing how much of the
On Sun, Jun 25, 2006 at 09:13:48PM +0300, Heikki Linnakangas wrote:
> >If you can't expire the old row because one of the indexed columns was
> >modified, I see no reason to try to reduce the additional index entries.
>
> It won't enable early expiration, but it means less work to do on update.
>
Ok, let's step back to discuss this again. Sorry for the length -- this
is a description of the problem I'm trying to solve, the issues I found,
and how I tried to solve them.
The relminxid Patch
===
What I'm after is not freezing for read-only media, nor archive, nor
read-only
On Mon, 2006-06-26 at 16:28 +0300, Alexandru Coseru wrote:
> billing=> select sum(duration)/60 from cdr__2006 where
> callstarttime<'2006-06-19 00:00:00';
> ERROR: invalid page header in block 3527 of relation "cdr__2006_04_22";
>
> Table cdr__2006_04_22 is a child of cdr__2006_04 , which is a
Tom Lane wrote:
> I wrote:
> > IIRC, newer BSDen use a kernel call for this, so you should be able to
> > measure it on your own machine. Just tweak ps_status.c to force it to
> > select PS_USE_NONE instead of PS_USE_SETPROCTITLE to generate a
> > comparison case. I'll try it on my old HPUX box t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yep, I see 8% here. I will add a patch to allow the ps display to be
> turned off.
I think we'd still want a backend to set the PS display once with its
identification data (user/DB name and client address). It's just the
transient activity updates tha
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Oh, good point. Do we remove stats_command_string?
You mean, remove the option to turn it off? I don't think so. Aside
from whatever remaining overhead there is, there's a possible security
argument to be made that one might not want one's commands ex
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yep, I see 8% here. I will add a patch to allow the ps display to be
> > turned off.
>
> I think we'd still want a backend to set the PS display once with its
> identification data (user/DB name and client address). It's just the
>
> > head of the chain yet. With an index scan, finding the head is
easy,
> > but for a sequential scan, it seems more difficult, and we don't
have
> > any free space in the tail of the chain to maintain a pointer to the
head.
>
> Thinking some more, there will need to be a bit to uniquely
> i
What about increasing the size of an existing index entry? Can that be
done easily when a new row is added?
I'd say it looks pretty much like inserting a new index tuple...
Say "value" is the indexed column.
Find first page in the index featuring "value".
1 If t
> -Original Message-
> From: Devrim GUNDUZ [mailto:[EMAIL PROTECTED]
> Sent: 26 June 2006 15:03
> To: Dave Page
> Cc: Robert Treat; pgsql-hackers@postgresql.org; Andrew
> Dunstan; Tom Lane
> Subject: Re: Anyone still care about Cygwin? (was Re:
> [HACKERS] [CORE] GPL
>
>
> Ok, I talk
PFC wrote:
>
> There were some talks lately about compression.
> With a bit of lateral thinking I guess this can be used to contain the
> bloat induced by updates.
> Of course this is just my hypothesis.
>
> Compression in indexes :
>
> Instead of storing (value,
"Bort, Paul" <[EMAIL PROTECTED]> writes:
> Tom Lane said:
>> As long as the code using it never tries to access any
>> of the missing fields (t_xmin through t_ctid), this would work exactly
>> like a normal HeapTuple.
> This sounds like a security risk.
No more than any other wild-pointer problem
There were some talks lately about compression.
With a bit of lateral thinking I guess this can be used to contain the
bloat induced by updates.
Of course this is just my hypothesis.
Compression in indexes :
Instead of storing (value, tuple identifier) keys in the i
> -Original Message-
> From: Robert Treat [mailto:[EMAIL PROTECTED]
> Sent: 26 June 2006 16:08
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org; Andrew Dunstan; Tom Lane;
> Devrim GUNDUZ
> Subject: Re: Anyone still care about Cygwin? (was Re:
> [HACKERS] [CORE] GPL
>
> Right, but I
Hannu Krosing wrote:
> > > pass 3: clean heap based on ctid from pass 1
> > >
> > > If yo do it this way, you dont need to invent new data structures to
> > > pass extra info about CITC internals to passes 2 and 3
> > >
> > > On more thing - when should free space map be notified about free space
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Mon, Jun 26, 2006 at 10:50:26AM -0400, Bruce Momjian wrote:
> > > > I suppose we would also change the index_getmulti() function to return
> > > > a set of ctids plus flags so the caller knows to follow the chains,
> > > > right?
>
Tom Lane said:
>
> To make use of a TruncatedTuple, we'd set up a temporary HeapTupleData
> struct with its t_data field pointing 16 bytes before the start of the
> TruncatedTuple. As long as the code using it never tries to
> access any
> of the missing fields (t_xmin through t_ctid), this woul
Ühel kenal päeval, E, 2006-06-26 kell 16:58, kirjutas Martijn van
Oosterhout:
> On Mon, Jun 26, 2006 at 10:50:26AM -0400, Bruce Momjian wrote:
> > > > I suppose we would also change the index_getmulti() function to return
> > > > a set of ctids plus flags so the caller knows to follow the chains,
>
On Monday 26 June 2006 03:28, Dave Page wrote:
> > -Original Message-
> > From: Robert Treat [mailto:[EMAIL PROTECTED]
> > Sent: 24 June 2006 20:50
> > To: pgsql-hackers@postgresql.org
> > Cc: Andrew Dunstan; Tom Lane; Dave Page
> > Subject: Re: Anyone still care about Cygwin? (was Re:
> >
Ühel kenal päeval, E, 2006-06-26 kell 10:50, kirjutas Bruce Momjian:
> Hannu Krosing wrote:
> > ?hel kenal p?eval, E, 2006-06-26 kell 14:56, kirjutas Martijn van
> > Oosterhout:
> > > On Mon, Jun 26, 2006 at 07:17:31AM -0400, Bruce Momjian wrote:
> > > > Correct! We use the same pointers used by n
On Mon, Jun 26, 2006 at 10:50:26AM -0400, Bruce Momjian wrote:
> > > I suppose we would also change the index_getmulti() function to return
> > > a set of ctids plus flags so the caller knows to follow the chains,
> > > right?
> >
> > It is probably better to always return the pointer to the head
Martijn van Oosterhout writes:
> On Mon, Jun 26, 2006 at 10:36:00AM -0400, Tom Lane wrote:
>> Unlike the case with sort temp files, it's important to be able to
>> access the stored data without moving/copying it. So, not wishing to
>> duplicate all the tuple access machinery we have already, I'm
Ühel kenal päeval, E, 2006-06-26 kell 09:10, kirjutas Mark Woodward:
> > Ühel kenal päeval, R, 2006-06-23 kell 17:27, kirjutas Bruce Momjian:
> >> Jonah H. Harris wrote:
> >> > On 6/23/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> > > What I see in this discussion is a huge amount of "the grass mu
Hannu Krosing wrote:
> ?hel kenal p?eval, E, 2006-06-26 kell 14:56, kirjutas Martijn van
> Oosterhout:
> > On Mon, Jun 26, 2006 at 07:17:31AM -0400, Bruce Momjian wrote:
> > > Correct! We use the same pointers used by normal UPDATEs, except we set
> > > a bit on the old tuple indicating it is a si
On Mon, Jun 26, 2006 at 10:36:00AM -0400, Tom Lane wrote:
> While looking at the recently-noticed problem that HashAggregate nodes
> store more columns of the input than they need to, I couldn't help
> noticing how much of the hashtable space goes into HeapTuple header
> overhead. A couple months
>> > The installer for 8.1 will let you pick UNICODE encoding
>> during setup.
>>
>> What if he uses initdb directly?
>
>Then it should be a simple "-E UNICODE", just as on unix.
>
>//Magnus
Hello, I'm the guy that post this question on psql-es-ayuda.
Thanks to Alvaro for forward here.
I would l
While looking at the recently-noticed problem that HashAggregate nodes
store more columns of the input than they need to, I couldn't help
noticing how much of the hashtable space goes into HeapTuple header
overhead. A couple months ago we were able to get a useful improvement
in sorting by not sto
Hello..
During a regular query , I got an werd error:
billing=> select sum(duration)/60 from cdr__2006 where
callstarttime<'2006-06-19 00:00:00';
ERROR: invalid page header in block 3527 of relation "cdr__2006_04_22";
Table cdr__2006_04_22 is a child of cdr__2006_04 , which is a child to
cd
Ühel kenal päeval, E, 2006-06-26 kell 14:56, kirjutas Martijn van
Oosterhout:
> On Mon, Jun 26, 2006 at 07:17:31AM -0400, Bruce Momjian wrote:
> > Correct! We use the same pointers used by normal UPDATEs, except we set
> > a bit on the old tuple indicating it is a single-index tuple, and we
> > do
On 6/26/06, Mark Woodward <[EMAIL PROTECTED]> wrote:
Is it really nessisary make personal comments like this? Lets discuss
"ideas" not personalities or people.
Chill dude :) All I was saying is that if you look at past threads,
this is a heavily discussed and near-religious topic. Doing some
Hi,
On Mon, 2006-06-26 at 08:28 +0100, Dave Page wrote:
>
> Devrim was working with another potential contributor though, dunno
> how that's going.
Ok, I talked with them now. They need the following information:
- What type of hardware do we need? Is an Opteron enough? Memory? Disk?
- Do we n
On Mon, June 26, 2006 9:37 am, Mark Woodward wrote:
>> On 6/24/06, Mark Woodward <[EMAIL PROTECTED]> wrote:
>>
>>> I originally suggested a methodology for preserving MVCC and everyone
>>> is confusing it as update "in place," this isnot what I intended.
>>
>> Actually, you should've presented your
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Martijn van Oosterhout wrote:
> > -- Start of PGP signed section.
> > > On Mon, Jun 26, 2006 at 07:17:31AM -0400, Bruce Momjian wrote:
> > > > Correct! We use the same pointers used by normal UPDATEs, except we set
> > > > a bit on the old tuple indi
> On 6/24/06, Mark Woodward <[EMAIL PROTECTED]> wrote:
>> I originally suggested a methodology for preserving MVCC and everyone is
>> confusing it as update "in place," this isnot what I intended.
>
> Actually, you should've presented your idea as performing MVCC the way
> Firebird does... the idea
Bruce Momjian wrote:
> Martijn van Oosterhout wrote:
> -- Start of PGP signed section.
> > On Mon, Jun 26, 2006 at 07:17:31AM -0400, Bruce Momjian wrote:
> > > Correct! We use the same pointers used by normal UPDATEs, except we set
> > > a bit on the old tuple indicating it is a single-index tuple
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Mon, Jun 26, 2006 at 07:17:31AM -0400, Bruce Momjian wrote:
> > Correct! We use the same pointers used by normal UPDATEs, except we set
> > a bit on the old tuple indicating it is a single-index tuple, and we
> > don't create index
I did some research on this item. I downloaded the source code to WN from:
http://hopf.math.northwestern.edu/index.html
I could only find the most recent version. wn-2.4.7. I then looked at
its image.c file:
http://momjian.us/expire/image.c
I looked at the last two functions
> -Original Message-
> From: Robert Treat [mailto:[EMAIL PROTECTED]
> Sent: 24 June 2006 20:50
> To: pgsql-hackers@postgresql.org
> Cc: Andrew Dunstan; Tom Lane; Dave Page
> Subject: Re: Anyone still care about Cygwin? (was Re:
> [HACKERS] [CORE] GPL
>
>
> Dave,
>
> wasn't someone
> Heikki Linnakangas wrote:
>> On Mon, 26 Jun 2006, Jan Wieck wrote:
>>
>> > On 6/25/2006 10:12 PM, Bruce Momjian wrote:
>> >> When you are using the update chaining, you can't mark that index row
>> as
>> >> dead because it actually points to more than one row on the page,
>> some
>> >> are non-vi
On Mon, Jun 26, 2006 at 07:17:31AM -0400, Bruce Momjian wrote:
> Correct! We use the same pointers used by normal UPDATEs, except we set
> a bit on the old tuple indicating it is a single-index tuple, and we
> don't create index entries for the new tuple. Index scan routines will
> need to be tau
> Ãhel kenal päeval, R, 2006-06-23 kell 17:27, kirjutas Bruce Momjian:
>> Jonah H. Harris wrote:
>> > On 6/23/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> > > What I see in this discussion is a huge amount of "the grass must be
>> > > greener on the other side" syndrome, and hardly any recognition
Heikki Linnakangas wrote:
> On Mon, 26 Jun 2006, Jan Wieck wrote:
>
> > On 6/25/2006 10:12 PM, Bruce Momjian wrote:
> >> When you are using the update chaining, you can't mark that index row as
> >> dead because it actually points to more than one row on the page, some
> >> are non-visible, some a
Zeugswetter Andreas DCP SD wrote:
>
> > > On 6/25/2006 10:12 PM, Bruce Momjian wrote:
> > > >When you are using the update chaining, you can't mark that index
> row
> > > >as dead because it actually points to more than one row on the
> page,
> > > >some are non-visible, some are visible.
> > >
On Sat, Jun 24, 2006 at 02:45:33PM +0300, Volkan YAZICI wrote:
> I totally agree with the followed ugly style. But IMHO the recursive
> parsing (that is followed in pqParseInputN()) of received data is the main
> problem behind this. I think, it will even get harder everytime somebody
> try to to a
> > On 6/25/2006 10:12 PM, Bruce Momjian wrote:
> > >When you are using the update chaining, you can't mark that index
row
> > >as dead because it actually points to more than one row on the
page,
> > >some are non-visible, some are visible.
> >
> > Back up the truck ... you mean in the current
Alvaro Herrera wrote:
> Jan Wieck wrote:
> > On 6/25/2006 10:12 PM, Bruce Momjian wrote:
> > >When you are using the update chaining, you can't mark that index row as
> > >dead because it actually points to more than one row on the page, some
> > >are non-visible, some are visible.
> >
> > Back up
Jan Wieck wrote:
> On 6/25/2006 10:12 PM, Bruce Momjian wrote:
> > When you are using the update chaining, you can't mark that index row as
> > dead because it actually points to more than one row on the page, some
> > are non-visible, some are visible.
>
> Back up the truck ... you mean in the cu
On Sun, 2006-06-25 at 05:29, Alvaro Herrera wrote:
> Mark Woodward wrote:
> > I originally suggested a methodology for preserving MVCC and everyone is
> > confusing it as update "in place," this isnot what I intended.
>
> It doesn't make sense, but maybe vacuuming a page would. Naturally, it
> wo
On Mon, 26 Jun 2006, Jan Wieck wrote:
On 6/25/2006 10:12 PM, Bruce Momjian wrote:
When you are using the update chaining, you can't mark that index row as
dead because it actually points to more than one row on the page, some
are non-visible, some are visible.
Back up the truck ... you mean i
84 matches
Mail list logo
