Re: unlogged tables vs. GIST - Mailing list pgsql-hackers
| From | Jeevan Chalke |
|---|---|
| Subject | Re: unlogged tables vs. GIST |
| Date | |
| Msg-id | CAM2+6=UTts3rAM4PoH1F475M9nsuquasnN+Z_rDzX6fmfYXx=A@mail.gmail.com Whole thread Raw |
| In response to | Re: unlogged tables vs. GIST (Robert Haas <robertmhaas@gmail.com>) |
| Responses |
Re: unlogged tables vs. GIST
|
| List | pgsql-hackers |
Hi Robert / Tom
I think to support GiST with unlogged table we need to do three things:
1. Teach the buffer manager that the LSN of a page not marked
BM_PERMANENT can be ignored
2. Teach GetXLogRecPtrForTemp() to allocate fake LSNs for GiST buffers
using a 64-bit, counter that is persisted across clean shutdowns
3. Remove the error checks that prevent creating an unlogged GiST
index and update the documentation accordingly
PFA, patch which try to do above things.
For (2), I have added a new function called, GetXLogRecPtrForUnloogedRel()
which returns a fake LSN for GiST indexes. However, I have removed
GetXLogRecPtrForTemp() function and added its functionality inside this new
function itself to avoid complexity.
With this patch I am able to create GiST for unlogged tables.
It works well with my examples.
Also make check has no issues.
Please have a look and let me know your views.
Thanks
I think to support GiST with unlogged table we need to do three things:
1. Teach the buffer manager that the LSN of a page not marked
BM_PERMANENT can be ignored
2. Teach GetXLogRecPtrForTemp() to allocate fake LSNs for GiST buffers
using a 64-bit, counter that is persisted across clean shutdowns
3. Remove the error checks that prevent creating an unlogged GiST
index and update the documentation accordingly
PFA, patch which try to do above things.
For (2), I have added a new function called, GetXLogRecPtrForUnloogedRel()
which returns a fake LSN for GiST indexes. However, I have removed
GetXLogRecPtrForTemp() function and added its functionality inside this new
function itself to avoid complexity.
With this patch I am able to create GiST for unlogged tables.
It works well with my examples.
Also make check has no issues.
Please have a look and let me know your views.
Thanks
On Sat, Dec 18, 2010 at 7:20 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Fri, Dec 17, 2010 at 4:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:If we read the bits while someone else is writing them, we'll get
>> Since these bits will only be set/cleared when the buffer mapping is
>> changed, can we examine this bit without taking the spinlock?
>
> Only if you're willing for the result to be unreliable.
either the old or the new value, but the BM_FLUSH_XLOG bit will be the
same either way. When FlushBuffer() is called, a shared content log
and a pin are held, so the buffer can't be renamed under us. If
that's really unacceptable, we can do something like the attached, but
I think this is unnecessarily gross. We already assume in other
places that the read or write of an integer is atomic. In this case
we don't even need it to be fully atomic - we just need the particular
byte that contains this bit not to go through some intermediate state
where the bit is unset. Is there really a memory architecture out
there that's crazy enough to let such a thing happen? If so, I'd
expect things to be breaking right and left on that machine anyway.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Jeevan B Chalke
Senior Software Engineer, R&D
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
Phone: +91 20 30589500
Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb
This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message.
Attachment
pgsql-hackers by date: