Re: [PERFORM] Slow join using network address function

> is a datatype that contains > a range of IPv4 addresses, and which has the various operators to > make it GIST indexable. Great, this looks very promising. > No cast operators between ipr and inet types. Any way to work around this, short of dumping a

Re: [PERFORM] Slow join using network address function

"Eric Jain" <[EMAIL PROTECTED]> writes: >> is a datatype that contains >> a range of IPv4 addresses, and which has the various operators to >> make it GIST indexable. > Great, this looks very promising. >> No cast operators between ipr and inet types. > An

Re: [PERFORM] Slow join using network address function

Tom Lane wrote: "Eric Jain" <[EMAIL PROTECTED]> writes: is a datatype that contains a range of IPv4 addresses, and which has the various operators to make it GIST indexable. Great, this looks very promising. No cast operators between ipr

Re: [PERFORM] Column correlation drifts, index ignored again

Kevin, > 1. set enable_seqscan = on > 2. set random_page_cost = > 3. EXPLAIN ANALYZE query > 4. record the ratio of estimated to actual scan times. > 5. set enable_seqscan = off > 6. set random_page_cost = > 7. EXPLAIN ANALYZE query > 8. record the actual index scan time(s) > 9. tweak r

Re: [PERFORM] Slow join using network address function

On Tue, Feb 24, 2004 at 10:23:22AM -0500, Tom Lane wrote: > "Eric Jain" <[EMAIL PROTECTED]> writes: > >> is a datatype that contains > >> a range of IPv4 addresses, and which has the various operators to > >> make it GIST indexable. > > > Great, this looks v

Re: [PERFORM] Slow join using network address function

On Tue, Feb 24, 2004 at 01:07:10PM +0100, Eric Jain wrote: > > is a datatype that contains > > a range of IPv4 addresses, and which has the various operators to > > make it GIST indexable. > > Great, this looks very promising. > > > No cast operators betw

Re: [PERFORM] [PERFORMANCE] slow small delete on large table

On Monday February 23 2004 10:23, Tom Lane wrote: > "Ed L." <[EMAIL PROTECTED]> writes: > > If I could say it the way I think for a simple example, it'd be > > like this: > > > > delete from mytable > > where posteddatetime < now() - '90 days' > > limit 100; > > > > Of course, that's no

Re: [PERFORM] Column correlation drifts, index ignored again

Josh Berkus <[EMAIL PROTECTED]> writes: > Kevin, >> 1. set enable_seqscan = on >> 2. set random_page_cost = >> 3. EXPLAIN ANALYZE query >> 4. record the ratio of estimated to actual scan times. >> 5. set enable_seqscan = off >> 6. set random_page_cost = >> 7. EXPLAIN ANALYZE query >> 8. r

Re: [PERFORM] Column correlation drifts, index ignored again

Tom Lane wrote: > Josh Berkus <[EMAIL PROTECTED]> writes: > > Kevin, > >> 1. set enable_seqscan = on > >> 2. set random_page_cost = > >> 3. EXPLAIN ANALYZE query > >> 4. record the ratio of estimated to actual scan times. > >> 5. set enable_seqscan = off > >> 6. set random_page_cost = > >>

Re: [PERFORM] Column correlation drifts, index ignored again

On Tuesday February 24 2004 1:14, Kevin Brown wrote: > > One problem I've been running into is the merge join spilling to disk > because sort_mem isn't big enough. The problem isn't that this is > happening, it's that I think the planner is underestimating the impact > that doing this will have on

Re: [PERFORM] Column correlation drifts, index ignored again

Ed L. wrote: > How do you know the merge join is spilling to disk? How are you identifying > that? Just assuming from vmstat? iostat? The existence of files in $PG_DATA/base//pgsql_tmp while the query is running, combined with the EXPLAIN output (which shows what sorts and joins are being perf

Re: [PERFORM] Column correlation drifts, index ignored again

Kevin Brown <[EMAIL PROTECTED]> writes: > One problem I've been running into is the merge join spilling to disk > because sort_mem isn't big enough. The problem isn't that this is > happening, it's that I think the planner is underestimating the impact > that doing this will have on the time the m

Re: [PERFORM] Speed up a function?CREATE TABLE readings ( "when" TIMESTAMP DEFAULT timeofday()::timestamp NOT NULL PRIMARY KEY, "barometer" FLOAT DEFAULT NULL,

Robert Creager <[EMAIL PROTECTED]> writes: > I've implemented a couple of functions ala date_trunc (listed at the bottom) > [ and they're too slow ] Well, it's hardly surprising that a function that invokes date_trunc and half a dozen other comparably-expensive operations should be half a dozen ti

Re: [PERFORM] Slow join using network address function

On Tue, Feb 24, 2004 at 09:14:42AM -0800, Steve Atkins wrote: > On Tue, Feb 24, 2004 at 01:07:10PM +0100, Eric Jain wrote: > > > is a datatype that contains > > > a range of IPv4 addresses, and which has the various operators to > > > make it GIST indexable.

[PERFORM] Materialized View Summary

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've written a summary of my findings on implementing and using materialized views in PostgreSQL. I've already deployed eagerly updating materialized views on several views in a production environment for a company called RedWeek: http://redweek.com