Re: [PERFORM] memcached and PostgreSQL

update happens and the commit later fails, or the commit happens and the cache update never happens. Having pgmemcache delete, not replace data addresses this second issue. -sc -- Sean Chittenden ---(end of broadcast)--- TIP 3: if posting/reading

Re: [PERFORM] memcached and PostgreSQL

you're willing to swallow the financial cost of cache discrepancies. -sc -- Sean Chittenden ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html

Re: [PERFORM] memcached and PostgreSQL

. -sc -- Sean Chittenden ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Re: [PERFORM] Need advice on postgresql.conf settings

by disabling persistent connections, this shouldn't be a problem. -sc -- Sean Chittenden ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] Anything to be gained from a 'Postgres Filesystem'?

the OS the following hints: MADV_NORMAL, MADV_SEQUENTIAL, MADV_RANDOM, MADV_WILLNEED, MADV_DONTNEED, and MADV_FREE. :) -sc -- Sean Chittenden ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your

Re: [PERFORM] mmap (was First set of OSDL Shared Mem scalability results, some wierdness ...

of project in hopes of a 3% win. Would it be helpful if I created a test program that demonstrated that the execution path for writing mmap(2)'ed pages as outlined above? -sc -- Sean Chittenden ---(end of broadcast)--- TIP 7: don't forget to increase

Re: [PERFORM] mmap (was First set of OSDL Shared Mem scalability results, some wierdness ...

caching done currently (caching in PostgreSQL and the kernel) by pushing the cache into the kernel... but without PostgreSQL knowing it's working on a page that's in the kernel. Please ask questions if you have them. -sc -- Sean Chittenden ---(end of broadcast

Re: [PERFORM] First set of OSDL Shared Mem scalability results, some wierdness ...

cache should ever use mmap(2). In order for this to work on HPUX, msync(2) would need to be used. -sc -- Sean Chittenden ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's

Re: [PERFORM] go for a script! / ex: PostgreSQL vs. MySQL

PGBLOCKSIZE to the values 16K or 32K to change the block size, but the default remains 8K. http://lists.freebsd.org/pipermail/freebsd-database/2003-October/000111.html -sc -- Sean Chittenden ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] go for a script! / ex: PostgreSQL vs. MySQL

it is maxed out now. YMMV. -sc -- Sean Chittenden ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] go for a script! / ex: PostgreSQL vs. MySQL

widely deployed (I would be surprised if any of the supported PG platforms didn't have mmap()). -sc -- Sean Chittenden ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister

Re: [PERFORM] go for a script! / ex: PostgreSQL vs. MySQL

, is the size of a PG page, so, if you tweak PG's page size, you have to change this constant (*grumbles*). -sc -- Sean Chittenden ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister

Re: [PERFORM] go for a script! / ex: PostgreSQL vs. MySQL

dependant, which is infuriating when copying configs from DB to DB. I wish pgsql had some notion of percentages for values that end with a '%'. -sc -- Sean Chittenden ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PERFORM] count(*) slow on large tables

in a dynamically executed query. CREATE AGGREGATE CACHE anyone? -sc -- Sean Chittenden ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] Performance issue

running Red hat 8. Some of my conf entries that I have changed follow shared_buffers = 3700 effective_cache_size = 4000 sort_mem = 32168 Have you twiddled with your wal_buffers or checkpoint_segments? Might be something to look at. -sc -- Sean Chittenden ---(end

Re: [PERFORM] FreeBSD page size

, UPDATEs, and both sequential scans as well as index scans for random and sequentially ordered tuples. It's similar to pgbench, except it generates its own data, uses pthreads (chears on KSE!), and returns more fine grained timing information for the various activities. -sc -- Sean Chittenden

Re: [PERFORM] bad estimates

tables, but this is a big problem and something I'm going to spend some time validating later today. I think Manfred's patch is pretty good and certainly better than where we are but I haven't used it yet to see if it's the magic ticket for many of these index problems. -sc -- Sean Chittenden

Re: [PERFORM] The results of my PostgreSQL/filesystem performance tests

is still being unwound from Giant), but should out perform Linux as well if industry experience iss any indicator. -sc -- Sean Chittenden ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send

Re: [PERFORM] The results of my PostgreSQL/filesystem performance tests

to the OS, one reads 16K of data off disk and returns the 1st page, the 2nd call pulls the 2nd block from the FS cache. In making things 16K, it avoids the need for the 2nd system call which is where the performance difference is coming from, afaikt. -sc -- Sean Chittenden Index: src/include

Re: [PERFORM] The results of my PostgreSQL/filesystem performance tests

-- Sean Chittenden ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly

Re: [PERFORM] Perfomance Tuning

/en_US.ISO8859-1/books/handbook/ If anyone on this list has any issues with the documentation, please take them up with me _privately_ and I will do my best to either address or correct the problem. Now, back to our regularly scheduled and on topic programming... -sc -- Sean Chittenden

Re: [PERFORM] Moving postgresql.conf tunables into 2003...

=168478 width=12) (actual time=0.35..17.61 rows=320 loops=1) Index Cond: ((evtime (now() - '06:00'::interval)) AND (sensorid = 7)) Filter: (NOT action) Total runtime: 29.09 msec (11 rows) -- Sean Chittenden

Re: [PERFORM] Moving postgresql.conf tunables into 2003...

to automatically determine the effective cache size /dev/stderr ;; esac -sc -- Sean Chittenden ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster