Eric Jain [EMAIL PROTECTED] writes:
http://word-to-the-wise.com/ipr.tgz 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
Tom Lane wrote:
Eric Jain [EMAIL PROTECTED] writes:
http://word-to-the-wise.com/ipr.tgz 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
Kevin,
1. set enable_seqscan = on
2. set random_page_cost = some really high value to force seqscans
3. EXPLAIN ANALYZE query
4. record the ratio of estimated to actual scan times.
5. set enable_seqscan = off
6. set random_page_cost = rough estimate of what it should be
7. EXPLAIN
On Tue, Feb 24, 2004 at 10:23:22AM -0500, Tom Lane wrote:
Eric Jain [EMAIL PROTECTED] writes:
http://word-to-the-wise.com/ipr.tgz 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.
On Tue, Feb 24, 2004 at 01:07:10PM +0100, Eric Jain wrote:
http://word-to-the-wise.com/ipr.tgz 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
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 not legal 7.3.4 syntax.
Josh Berkus [EMAIL PROTECTED] writes:
Kevin,
1. set enable_seqscan = on
2. set random_page_cost = some really high value to force seqscans
3. EXPLAIN ANALYZE query
4. record the ratio of estimated to actual scan times.
5. set enable_seqscan = off
6. set random_page_cost = rough
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Kevin,
1. set enable_seqscan = on
2. set random_page_cost = some really high value to force seqscans
3. EXPLAIN ANALYZE query
4. record the ratio of estimated to actual scan times.
5. set enable_seqscan = off
6. set
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 the
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/db-oid/pgsql_tmp while the
query is running, combined with the EXPLAIN output (which shows what
sorts and joins are being
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 merge
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 times
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:
http://word-to-the-wise.com/ipr.tgz is a datatype that contains
a range of IPv4 addresses, and which has the various operators to
make it GIST indexable.
Great,
-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:
14 matches
Mail list logo
