Bill Howe <[EMAIL PROTECTED]> writes:
> I need the lovely index scan, but my table is hidden behind a view, and
> all I get is the ugly sequential scan. Any ideas on how to convince the
> optimizer to unfold the subquery properly?
You should provide some context in this sort of gripe, like which
On Mon, Feb 05, 2007 at 18:01:05 -0500,
Mark Stosberg <[EMAIL PROTECTED]> wrote:
>
> It's also notable that the units used are meters, not miles like
> geo_distance(). That's what the magic number of "16093.44" is-- 10 miles
> converted to meters.
You can change the earth() function in earthdis
"Karen Hill" <[EMAIL PROTECTED]> writes:
> I have a pl/pgsql function that is inserting 200,000 records for
> testing purposes. What is the expected time frame for this operation
> on a pc with 1/2 a gig of ram and a 7200 RPM disk?
I think you have omitted a bunch of relevant facts. Bare INSERT
I have a pl/pgsql function that is inserting 200,000 records for
testing purposes. What is the expected time frame for this operation
on a pc with 1/2 a gig of ram and a 7200 RPM disk? The processor is
a 2ghz cpu. So far I've been sitting here for about 2 million ms
waiting for it to complete,
Why should these queries have different plans?
create table foo (a int PRIMARY KEY);
Q1: explain select max(a) from foo
> Result (cost=0.04..0.05 rows=1 width=0)
> InitPlan
>-> Limit (cost=0.00..0.04 rows=1 width=4)
> -> Index Scan Backward using foo_pkey on foo
> (cost=0.00
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:pgsql-performance-
> [EMAIL PROTECTED] On Behalf Of John Parnefjord
> Sent: Tuesday, January 30, 2007 2:05 AM
> Subject: Re: [PERFORM] Tuning
> EnterpriseDB advocates: 250 KB + 8.2 KB * shared_buffers + 14.2 kB *
> max_connections up t
Merlin Moncure wrote:
> On 2/5/07, Mark Stosberg <[EMAIL PROTECTED]> wrote:
>> Bruno Wolff III wrote:
>> > On Sat, Feb 03, 2007 at 14:00:26 -0500,
>> > Mark Stosberg <[EMAIL PROTECTED]> wrote:
>> >> I'm using geo_distance() from contrib/earthdistance would like to
>> find a
>> >> way to spend up
On Mon, Feb 05, 2007 at 14:47:25 -0500,
Mark Stosberg <[EMAIL PROTECTED]> wrote:
>
> This is also interesting. Is this approach practical if I want to index
> what's near each of about 40,000 US zipcodes, or the approach mostly
> useful if you there are just a small number of fixed points to add
On 2/5/07, Mark Stosberg <[EMAIL PROTECTED]> wrote:
Bruno Wolff III wrote:
> On Sat, Feb 03, 2007 at 14:00:26 -0500,
> Mark Stosberg <[EMAIL PROTECTED]> wrote:
>> I'm using geo_distance() from contrib/earthdistance would like to find a
>> way to spend up the geo distance calculation if possible
Bruno Wolff III wrote:
> On Sat, Feb 03, 2007 at 14:00:26 -0500,
> Mark Stosberg <[EMAIL PROTECTED]> wrote:
>> I'm using geo_distance() from contrib/earthdistance would like to find a
>> way to spend up the geo distance calculation if possible. This is for a
>> proximity search: "Show me adoptabl
Kirk Wythers wrote:
The 4G (32bit) limit may be where you hit the out of memory errors (or
is postgres get around that with it's caching?).
Any idea if postgres on OS X can truely access more that 4 gigs if the
64 bit version is built? I have tried building the 64 bit version of
some other a
11 matches
Mail list logo
