[HACKERS] Re: [BUGS] Re: BUG #9555: pg_dump for tables with inheritance recreates the table with the wrong order of columns

On Wed, Aug 27, 2014 at 11:24:53AM -0400, Tom Lane wrote: > On Wed, Aug 27, 2014 at 10:40:53AM -0400, Bruce Momjian wrote: > > I looked at this issue from March and I think we need to do something. > > In summary, the problem is that tables using inheritance can be dumped > > and reloaded with col

[HACKERS] Btree internal node data?

While looking into a btree internal page using pg_filedump against an int4 index generated pgbench, I noticed that only item 2 has length 8, which indicates that the index tuple has only tuple header and has no index data. In my understanding this indicates that the item is used to represent a down

Re: [HACKERS] Btree internal node data?

On Wed, Aug 27, 2014 at 7:08 PM, Tatsuo Ishii wrote: > While looking into a btree internal page using pg_filedump against an > int4 index generated pgbench, I noticed that only item 2 has length 8, > which indicates that the index tuple has only tuple header and has no > index data. In my understa

Re: [HACKERS] Specifying the unit in storage parameter

On Wed, Aug 27, 2014 at 10:59 PM, Alvaro Herrera wrote: > Not necessarily, because it's harmless. It's there for purely > aesthetical reasons, so it's your choice whether to add it or not. > Having it there is slightly easier on somebody reading the code, > perhaps. On my side, that's up to yo

Re: [HACKERS] [TODO] Track number of files ready to be archived in pg_stat_archiver

On Thu, Aug 28, 2014 at 7:37 AM, Julien Rouhaud wrote: > > Attached v2 patch implements this approach. All the work is still done > in pg_stat_get_archiver, as I don't think that having a specific > function for that information would be really interesting. Please be sure to add that to the next

Re: [HACKERS] Missing plpgsql.o Symbols on OS X

Please add -arch x86_64 to your LD_FLAGS and CFLAGS in your make file. -- Thanks & Regards, Ashesh Vashi EnterpriseDB INDIA: Enterprise PostgreSQL Company *http://www.linkedin.com/in/asheshvashi* On Wed, Aug 27, 2014 at

[HACKERS] Dense index?

While looking into pg_filedump output of int4 btree index, It strikes me that in leaf pages about 25% of page is wasted because of 8 byte alignment (MAXALIGN on 64bit architecture): an index tuple consists of 8 byte tuple header + 4 byte key + 4 byte alignment, thus 4/(8+4+4) = 25% is waste. I kno

Re: [HACKERS] Dense index?

Tatsuo Ishii writes: > I know that the alignment is required for faster memory access, but > sometimes we may want to save disk space for index to save I/O because > these days customers want to handle huge number of rows. To make index > more "dense", can we add an option something like "dense in

Re: [HACKERS] Dense index?

> Only if you want it to crash hard on most non-Intel architectures. Of course some CPU architecture prohibits none word boundary access and we need to do either: 1) do not allow to use the option on such an architecture 2) work hard to use temporary buffer which is properly aligned Best regard

Re: [HACKERS] Dense index?

On Wed, Aug 27, 2014 at 10:16 PM, Tatsuo Ishii wrote: > I know that the alignment is required for faster memory access, but > sometimes we may want to save disk space for index to save I/O because > these days customers want to handle huge number of rows. To make index > more "dense", can we add a

[HACKERS] Is this code safe?

Someone reported an issue on XL mailing list about the following code in fe-connect.c failing on Power PC platform: 1844 if (getsockopt(conn->sock, SOL_SOCKET, SO_ERROR, 1845(char *) &optval, &optlen) == -1) 1846 { 1847

Re: [HACKERS] Is this code safe?

Pavan Deolasee writes: > Can some kind of compiler optimisation reorder things such that the "else > if" expression is evaluated using the old, uninitialised value of optval? Any such behavior is patently illegal per the C standard. Not that that's always stopped compiler writers; but I think yo

Re: [HACKERS] postgresql latency & bgwriter not doing its job

Hello Aidan, If all you want is to avoid the write storms when fsyncs start happening on slow storage, can you not just adjust the kernel vm.dirty* tunables to start making the kernel write out dirty buffers much sooner instead of letting them accumulate until fsyncs force them out all at once?

<    1   2