>Ryan Mahoney <[EMAIL PROTECTED]> writes:
>> Index Scan using pa_zipcode_proximity_pk on pa_zipcode_proximity (cost=
>> 0.00..13.53 rows=3 width=862)
>>Index Cond: ((zipcode = '11103'::bpchar) AND (proximity <= 100))
>> (183 rows)
>
>Hmm ... evidently zipcode is declared as type char(5) (note
Gavin Sherry <[EMAIL PROTECTED]> writes:
> I've been thinking about resource management and postgres. I want to
> develop a user profile system (a-la oracle) which allows a DBA to
> restrict/configure access to system resources. This would allow a DBA to
> configure how much CPU time can be used pe
Hi all,
I've been thinking about resource management and postgres. I want to
develop a user profile system (a-la oracle) which allows a DBA to
restrict/configure access to system resources. This would allow a DBA to
configure how much CPU time can be used per query/session for any user,
the number
Ryan Mahoney <[EMAIL PROTECTED]> writes:
> Index Scan using pa_zipcode_proximity_pk on pa_zipcode_proximity (cost=
> 0.00..13.53 rows=3 width=862)
>Index Cond: ((zipcode = '11103'::bpchar) AND (proximity <= 100))
> (183 rows)
Hmm ... evidently zipcode is declared as type char(5) (note the "b
The following statements do not utilize an index when executed inside a
plpgsql procedure, but does when executed interactively in psql!
Does not use index:
FOR somemorerows IN
SELECT zipcode_list
FROM pa_zipcode_proximity
WHERE zipcode = zipcode_in
AND proximity <= proximity_range_in
LOOP
Ryan Mahoney <[EMAIL PROTECTED]> writes:
> The following statements do not utilize an index when executed inside a
> plpgsql procedure, but does when executed interactively in psql!
I suspect you are not telling the full truth here.
> However:
> SELECT zipcode_list
> FROM pa_zipcode_proximity
The following statements do not utilize an index when executed inside a
plpgsql procedure, but does when executed interactively in psql!
Does not use index:
FOR somemorerows IN
SELECT zipcode_list
FROM pa_zipcode_proximity
WHERE zipcode = zipcode_in
AND proximity <= proximity_range_in
LOOP
I like the idea, and see need to keep a separate list of NULL values.
---
Tom Lane wrote:
> I have been looking into the possibility of using a hashtable to speed
> up "x IN (SELECT y FROM ...)" operations. Basically the id
Greg Stark <[EMAIL PROTECTED]> writes:
> I'm not sure but I think the way Oracle optimizes subselects is by
> transforming them into the equivalent join.
The point here is that there is no exactly equivalent join operation.
(Of course, given Oracle's known lack of standards-compliance on NULL
sem
Tom Lane <[EMAIL PROTECTED]> writes:
> I have been looking into the possibility of using a hashtable to speed
> up "x IN (SELECT y FROM ...)" operations.
That's certainly one of the join types that Oracle can perform, and it's
frequently by far the fastest.
I'm not sure but I think the way Or
unsubscribe
__
Yahoo! Cartoline: invia i tuoi auguri di Natale agli amici
http://it.yahoo.com/mail_it/foot/?http://it.greetings.yahoo.com
---(end of broadcast)---
TIP 2: you can get
I have been looking into the possibility of using a hashtable to speed
up "x IN (SELECT y FROM ...)" operations. Basically the idea is to run
the subselect once, loading its "y" outputs into an in-memory hashtable
(any duplicates can be discarded); then for each outer row, probe into
the hashtable
> http://www.cs.mcgill.ca/~kemme/papers/vldb00.html
Thanks for the link, Darren, I think everyone interested
in discussion should read it.
First, I like approach. Second, I don't understand why
ppl oppose pg-r & 2pc. 2pc is just simple protocol to
perform distributed commits *after* distributed co
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> On Fri, Dec 20, 2002 at 12:56:55PM -0500, Tom Lane wrote:
>> No. It would break client libraries, which only expect command tags
>> INSERT, UPDATE, DELETE to be followed by counts.
> And MOVE, right?
Mph ... PQcmdTuples only knows about INSERT/
Bruce Momjian <[EMAIL PROTECTED]> writes:
> It is easy to determine what tag to return? Remember the discussion on
> rules and that only the original tag should be returned. Is there
> always one obvious tag to an execute?
I would think we'd do it via the rule that we return the same thing
you'd
On Fri, Dec 20, 2002 at 12:56:55PM -0500, Tom Lane wrote:
>
> No. It would break client libraries, which only expect command tags
> INSERT, UPDATE, DELETE to be followed by counts.
And MOVE, right?
Jeroen
---(end of broadcast)---
TIP 6: Have yo
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think it should return "EXECUTE" with the counts from the commands.
> > Does that make sense?
>
> No. It would break client libraries, which only expect command tags
> INSERT, UPDATE, DELETE to be followed by counts. Also, INSERT
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think it should return "EXECUTE" with the counts from the commands.
> Does that make sense?
No. It would break client libraries, which only expect command tags
INSERT, UPDATE, DELETE to be followed by counts. Also, INSERT has two
numbers associated
Tom Lane wrote:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Good catch. Hmm this may be a serious problem because
> > there's no way to know the row count when we use EXECUTE
> > statements.
>
> I wonder if EXECUTE could/should be made to return the appropriate
> command status string for the
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Good catch. Hmm this may be a serious problem because
> there's no way to know the row count when we use EXECUTE
> statements.
I wonder if EXECUTE could/should be made to return the appropriate
command status string for the executed statement, instead of
20 matches
Mail list logo
