Re: [PATCHES] Repair cosmetic damage (done by pg_indent?)

IO now-a-days, so I agree with something less than 256. Not sure what would be best though. I do have a database that has both user-entered information as well as things like email addresses, so I could do some testing on that if people want. -- Decibel!, aka Jim Nasby

Re: [PATCHES] Repair cosmetic damage (done by pg_indent?)

On Sun, Jul 29, 2007 at 12:06:50PM +0100, Gregory Stark wrote: > "Decibel!" <[EMAIL PROTECTED]> writes: > > > On Fri, Jul 27, 2007 at 04:07:01PM +0100, Gregory Stark wrote: > >> Fwiw, do we really not want to compress anything smaller than 256 bytes > &

Re: [PATCHES] strpos() && KMP

strpos(att, 'word') > 0;" instead > "select .. where attr like '%word%'" > (strpos must be faster than regex). > > In general, this belongs to artificial expressions. In natural language KMP > is equal (execution time) > current str

Re: [PATCHES] Repair cosmetic damage (done by pg_indent?)

On Fri, Aug 03, 2007 at 06:12:09PM -0500, Decibel! wrote: > On Sun, Jul 29, 2007 at 12:06:50PM +0100, Gregory Stark wrote: > > "Decibel!" <[EMAIL PROTECTED]> writes: > > > > > On Fri, Jul 27, 2007 at 04:07:01PM +0100, Gregory Stark wrote: > > >&

Re: [PATCHES] Repair cosmetic damage (done by pg_indent?)

ing but 213 'x's. I can't do anything that changes what pg_class.relpages shows. -- Decibel!, aka Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) pgp4mGKOGGkJ0.pgp Description: PGP signature

Re: [PATCHES] strpos() && KMP

grade so we can see what that looks like (though I don't know if that's an issue in this case). -- Decibel!, aka Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) pgpGxMofKAc20.pgp Description: PGP signature

Re: [PATCHES] Reduce the size of PageFreeSpaceInfo on 64bit platform

file about 6 bytes per page is incorrect? -- Decibel!, aka Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) pgpTGjLFGE552.pgp Description: PGP signature

Re: [PATCHES] HOT patch - version 14

ge in the area. > > I would still vote for disabling HOT on catalogs unless you see > strong value in it. What about ANALYZE? Doesn't that do a lot of updates? BTW, I'm 100% in favor of pushing system catalog HOT until later; it's be silly to risk not getting hot in 8.3 because

Re: [PATCHES] [HACKERS] Proposal for Null Bitmap Optimization(for TrailingNULLs)

nally? Also, testing on 64 bit would be interesting. -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature

Re: [PATCHES] Proposed patch to disallow password=foo in database name parameter

in a ditch over it. On the other hand, warning about it in the docs would probably be a good idea... -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 pgpqQC74CaoF8.pgp Description: PGP signature

Re: [PATCHES] Better default_statistics_target

seen anything but a performance increase or no change when going from 10 to 100. In most cases there's a noticeable improvement since it's common to have over 100k rows in a table, and there's just no way to capture any kind of a real picture of that with only 10 buckets. -- Deci

Re: [PATCHES] 2WRS [WIP]

ing for. > > > > not actually, because your patch removes an improvement that was > included in 8.3... > what you will have to do (if someone has a better solution feel free > to comment on this) is to manually merge your 8.2's patch into the > 8.3's source and then g