Search Postgresql Archives

Re: Pinning buffers for long times like outer joins might do.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tzahi Fadida <tzahi_ml@xxxxxxxxxxxxx> writes:
> I am writing an algorithm in a dynamic c library and using heap_fetch.
> I want to pin strategic buffers for long times like an Outer
> joins might do for the inner table.

> Do i to also need to lock the table somehow? 

You didn't say enough about the context.  It is *always* necessary to
have some type of lock on a table you are accessing --- otherwise some
other backend could drop the table out from under you.  But in many
scenarios this is taken care of at a pretty high level, like executor
startup.  What is your "algorithm" and when is it applied?  How does it
get the table to be accessed?

> I am only reading the tuple but maybe other transactions will
> want to write to it and when I am looping over
> the table like in an outer join does I can get different
> values and I want to avoid that.
> or that can't happen when pinning?

Pinning has nothing to do with that --- maintaining a consistent
snapshot setting does.

> Another question, when a column attribute is toasted,
> do I need to do another heap_fetch aside from the main
> table to fetch the data from the adjoined toasted table?
> How do I also pin the toasted table buffer pages?

No, you do a DETOAST_DATUM call.

> And last general question, 
> what is the best way to compare two datums?
> datumIsEqual doc says its not enough because of
> different representations, and if its toasted it won't
> work (maybe if its detoasted first).

You really should locate the datatype's equality function and call that.
datumIsEqual is a kluge that is only safe to use in the very limited
context of equalfuncs.c (basically, it's OK to say that two Const nodes
are different if they are bitwise different, even if the represented
values are logically equal).

Look at array_eq() for an example of current best practice for this.

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
      message can get through to the mailing list cleanly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux