From: | Tzahi Fadida <Tzahi(dot)ML(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Help with casting and comparing. |
Date: | 2006-07-06 19:05:57 |
Message-ID: | 200607062205.57298.Tzahi.ML@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thursday 06 July 2006 21:55, Martijn van Oosterhout wrote:
> On Thu, Jul 06, 2006 at 07:43:20PM +0300, Tzahi Fadida wrote:
> > The downside is that i noticed that the CTID is removed from the tuple
> > if a cast occurs. Is there a way to tell postgresql to not remove the
> > CTID?
>
> Err, the fact the ctid is removed is really just a side-effect. With no
> adjusting of the output, you may just get the actual on-disk tuple. But
> as soon as you do some manipulation, you get a new tuple.
>
> > The other way, of course is to add CTID as an attribute in the query
> > but it seems less efficient since i am accessing it repeatedly.
>
> If you want the ctid, you have to ask for it.
>
> But this seems a little like premature optimisation. First, make it
> work, then make it fast. Once you've got it working you can worry about
> performance. Adding an extra column to the output costs very, very
> little compared to other things...
It works, i use this technique for index accesses. I am not worried about
getting this to work since i already tried this. I am more worried about
optimization. Well, it is probably the lesser evil of dealing with casting.
P.s. the code is running and can be found here:
http://pgfoundry.org/projects/fulldisjunction/
--
Regards,
Tzahi.
--
Tzahi Fadida
Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
WARNING TO SPAMMERS: see at
http://members.lycos.co.uk/my2nis/spamwarning.html
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Hallgren | 2006-07-06 20:02:44 | Re: [GENERAL] UUID's as primary keys |
Previous Message | Martijn van Oosterhout | 2006-07-06 18:55:21 | Re: Help with casting and comparing. |