Unix Technical Forum

Re: Tablespace-level Block Size Definitions

This is a discussion on Re: Tablespace-level Block Size Definitions within the pgsql Hackers forums, part of the PostgreSQL category; --> > The problem I see with this proposal is that the buffer manager knows > how to handle only ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > pgsql Hackers

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-11-2008, 05:09 AM
Zeugswetter Andreas DAZ SD
 
Posts: n/a
Default Re: Tablespace-level Block Size Definitions


> The problem I see with this proposal is that the buffer manager knows
> how to handle only a equally-sized pages. And the shared memory stuff
> gets sized according to size * num_pages. So what happens if a certain
> tablespace A with pagesize=X gets to have a lot of its pages cached,
> evicting pages from tablespace B with pagesize=Y, where Y < X?


You could create a separate bufferpool per page size. Of course that
has other disadvantages.

Is it really so difficult to create and attach another shmem segment ?

Andreas

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #2 (permalink)  
Old 04-11-2008, 05:09 AM
Dawid Kuroczko
 
Posts: n/a
Default Re: Tablespace-level Block Size Definitions

On 6/1/05, Zeugswetter Andreas DAZ SD <ZeugswetterA@spardat.at> wrote:
> You could create a separate bufferpool per page size. Of course that
> has other disadvantages.
>
> Is it really so difficult to create and attach another shmem segment ?


Well, I don't think it is much different from having two database clusters,
each with different block size. Hmm, perhaps it could be possible to
make them all available through one "virtual" DB host/port using
pg_pool even.

It shouldn't be too difficult to create benchmarks testing performance
of PostgreSQL under different block sizes, I guess. I wonder what
perfromance win is possible...

Regards,
Dawid

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #3 (permalink)  
Old 04-11-2008, 05:09 AM
Hannu Krosing
 
Posts: n/a
Default Re: Tablespace-level Block Size Definitions

On K, 2005-06-01 at 14:00 +0200, Dawid Kuroczko wrote:
> On 6/1/05, Zeugswetter Andreas DAZ SD <ZeugswetterA@spardat.at> wrote:
> > You could create a separate bufferpool per page size. Of course that
> > has other disadvantages.
> >
> > Is it really so difficult to create and attach another shmem segment ?

>
> Well, I don't think it is much different from having two database clusters,
> each with different block size. Hmm, perhaps it could be possible to
> make them all available through one "virtual" DB host/port using
> pg_pool even.
>
> It shouldn't be too difficult to create benchmarks testing performance
> of PostgreSQL under different block sizes, I guess. I wonder what
> perfromance win is possible...


Perhaps it is simpler to just put different tablespaces on different
disks and then play with filesystem readahead settings at disk level.

It's not exactly the same thing, but may solve at least some problems.

--
Hannu Krosing <hannu@skype.net>


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 04:42 AM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.2.0
www.UnixAdminTalk.com