[PERFORM] Size of empty varchar and size of index

Hello, I'm searching for two facts: How much space takes a varchar column if there is no value in it (NULL)? How much space needs a index of an integer column? Hope I post to the right list and hope anybody can help me. Thank you Greetings Achim ---(end of broadcast)---

Re: [PERFORM] [PATCHES] COPY FROM performance improvements

Mark, On 7/22/05 12:47 PM, "Mark Wong" <[EMAIL PROTECTED]> wrote: > On a single spindle: > > $ time dd if=/dev/zero of=bigfile bs=8k count=200 > 200+0 records in > 200+0 records out > > real2m8.569s > user0m0.725s > sys 0m19.633s This is super fast! 124MB/s seems too f

Re: [PERFORM] Looking for tips

Title: Re: [PERFORM] Looking for tips   Hi, I have a similar application, but instead of adding new items to the db once at time, I retrieve new IDs from a sequence (actually only every 10'000 times) and write a csv file from perl. When finished, I load all new record in one run with Copy.  

Re: [PERFORM] [PATCHES] COPY FROM performance improvements

Joshua, On 7/22/05 10:11 AM, "Joshua D. Drake" <[EMAIL PROTECTED]> wrote: > The database server is a PE (Power Edge) 6600 > > Database Server IO: > > [EMAIL PROTECTED] root]# /sbin/hdparm -tT /dev/sda > > /dev/sda: > Timing buffer-cache reads: 1888 MB in 2.00 seconds = 944.00 MB/sec > Ti

Re: [PERFORM] Huge performance problem between 7.4.1 and 8.0.3 - CS

I've now backed off to version 7.4.1, which doesn't exhibit the problems that 8.0.3 does. I guess I'll wait 'till the next version and see if any progress has occurred. Rob When grilled further on (Tue, 19 Jul 2005 22:49:08 -0600), Robert Creager <[EMAIL PROTECTED]> confessed: > When grilled f

Re: [PERFORM] re: performance decrease after reboot

It's likely that data is in filesystem (not database) cache the second time you run the query. See if the same thing happens when you stop and restart the postmaster (it likely wont), then do something like this to flush the filesystem cache (read a big file, can't give you a sample cmd because

[PERFORM] re: performance decrease after reboot

pgsql performance gurus, I sent the following message earlier this week. I have continued attempting to find something on the net that would explain this strange change of query plans, but nothing seems to apply. Are there any thoughts, such as possibly tweaking the database somehow to see if I

Re: [HACKERS] [PERFORM] Planner doesn't look at LIMIT?

Tom Lane wrote: >Could be. I went back to look at Sam Mason's report about three weeks >ago, and it definitely seems to explain his issue. I've just built a patched version as well and it appears to be doing what I think is the right thing now. I.e. actually picking the plan with the lower cost.