On Aug 23, 2005, at 10:02 AM, Ilja Golshtein wrote:
The only thing I am curios is ctid good for
anything from user point of view?
I have a very specific use for it -- to bypass the index on an
update. Something like this:
select ctid,user_id from users where ...
... do stuff based on us
Jim C. Nasby wrote:
A better solution is to use a combination of a timestamp and a sequence.
Why both? Because it's possible for the clock to be set back (though
this is something best avoided), and a sequence will eventually roll
over.
With the default MAXVALUE of a postgresql sequence (9 qu
On Tue, Aug 23, 2005 at 11:36:31PM -0500, Jim C. Nasby wrote:
> A better solution is to use a combination of a timestamp and a sequence.
> Why both? Because it's possible for the clock to be set back (though
> this is something best avoided), and a sequence will eventually roll
> over. It's imposs
On Tue, Aug 23, 2005 at 06:42:33PM -0700, Jeff Eckermann wrote:
> > I believe that's not necessarily true. If you select
> > a tuple and it's
> > ctid and it's updated more than once with a vacuum
> > in-between I believe
> > it could end up back in the same position, which
> > would mean the same
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > I believe that's not necessarily true. If you
> select a tuple and it's
> > ctid and it's updated more than once with a vacuum
> in-between I believe
> > it could end up back in the same position, which
> woul
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> I believe that's not necessarily true. If you select a tuple and it's
> ctid and it's updated more than once with a vacuum in-between I believe
> it could end up back in the same position, which would mean the same
> ctid.
This is the reason for the rec
--- "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 24, 2005 at 09:26:10AM +0930, Jeff
> Eckermann wrote:
> > The ctid value can be useful in a multi user
> application, to check whether a
> > record has been changed by another user, before
> committing changes.
> > Whenever a record is
On Wed, Aug 24, 2005 at 09:26:10AM +0930, Jeff Eckermann wrote:
> The ctid value can be useful in a multi user application, to check whether a
> record has been changed by another user, before committing changes.
> Whenever a record is updated the ctid value will be changed, so by storing
> the
""Ilja Golshtein"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello!
>
>>On Tue, Aug 23, 2005 at 09:15:42AM -0400, Robert Treat wrote:
>>> On Tuesday 23 August 2005 08:39, Ilja Golshtein wrote:
>>> >
>>> > select ctid from aaa where ctid in (select ctid from aaa limit 10);
>
>>A
On Tuesday 23 August 2005 15:55, Alvaro Herrera wrote:
> On Tue, Aug 23, 2005 at 06:02:05PM +0400, Ilja Golshtein wrote:
> > The only thing I am curios is ctid good for anything from user point
> > of view?
>
> No -- it changes far too frequently for that.
Oh I dunno... In general I'd agree with y
Tom Lane wrote:
It wouldn't be hard that I can see (just build hash and btree opclasses
for tid), but I'm pretty unclear on why bother. There's no use-case for
cross-table joins involving ctid, since you couldn't usefully store a
ctid referencing another table. The example Ilja showed was quit
On Tue, Aug 23, 2005 at 06:02:05PM +0400, Ilja Golshtein wrote:
> The only thing I am curios is ctid good for anything from user point
> of view?
No -- it changes far too frequently for that.
--
Alvaro Herrera ()
"Un poeta es un mundo encerrado en un hombre" (Victor Hugo)
-
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> If you are too worried about it, you could look at what is needed to
> implement hashjoin and mergejoin for ctids. I take it it isn't trivial,
> or it would be done already, but I don't think it's too hard (unless
> there is an implementation detail tha
On Tue, Aug 23, 2005 at 05:30:31PM +0400, Ilja Golshtein wrote:
> Hi!
>
> >> Could anybody help me with this [artificial] query
> >>
> >> select ctid from aaa where ctid in (select ctid from aaa limit 10);
>
> [skipped]
>
> >I think using an indexed field would probably be faster for you,
> >esp
Hi!
>> Could anybody help me with this [artificial] query
>>
>> select ctid from aaa where ctid in (select ctid from aaa limit 10);
[skipped]
>I think using an indexed field would probably be faster for you, especially
>>if you have a PK on the table.
I used to think ctid is the same as rowi
Michael Fuhr <[EMAIL PROTECTED]> writes:
>> On Tuesday 23 August 2005 08:39, Ilja Golshtein wrote:
>>> select ctid from aaa where ctid in (select ctid from aaa limit 10);
> Aside from that, ctid is of type tid, and its equality operator
> isn't hashable.
Nor mergejoinable, so there's not much sco
Hello!
>On Tue, Aug 23, 2005 at 09:15:42AM -0400, Robert Treat wrote:
>> On Tuesday 23 August 2005 08:39, Ilja Golshtein wrote:
>> >
>> > select ctid from aaa where ctid in (select ctid from aaa limit 10);
>Aside from that, ctid is of type tid, and its equality operator
>isn't hashable.
It is t
On Tue, Aug 23, 2005 at 09:15:42AM -0400, Robert Treat wrote:
> On Tuesday 23 August 2005 08:39, Ilja Golshtein wrote:
> >
> > select ctid from aaa where ctid in (select ctid from aaa limit 10);
> >
> > Nested Loop IN Join (cost=3.47..300325932.99 rows=10 width=6)
> > Join Filter: ("ou
On Tuesday 23 August 2005 08:39, Ilja Golshtein wrote:
> Hello!
>
> Could anybody help me with this [artificial] query
>
> select ctid from aaa where ctid in (select ctid from aaa limit 10);
>
> here is explained plan
>
> Nested Loop IN Join (cost=3.47..300325932.99 rows=10 width=6)
>
19 matches
Mail list logo
