On Thu, Oct 28, 2004 at 07:49:28PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Sun, Oct 24, 2004 at 04:11:53PM -0400, Tom Lane wrote:
> >> The test case you are showing is probably suffering from nonrandom
> >> placement of this particular data value; which is somethi
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Sun, Oct 24, 2004 at 04:11:53PM -0400, Tom Lane wrote:
>> The test case you are showing is probably suffering from nonrandom
>> placement of this particular data value; which is something that the
>> statistics we keep are too crude to detect.
> Isn
On Sun, Oct 24, 2004 at 04:11:53PM -0400, Tom Lane wrote:
> But the LIMIT will cut the cost of the seqscan case too. Given the
> numbers you posit above, about one row in five will have 'myval', so a
> seqscan can reasonably expect to hit the first matching row in the first
> page of the table. T
Jaime Casanova wrote:
[...]
In http://www.postgresql.org/docs/faqs/FAQ.html under
"4.8) My queries are slow or don't make use of the
indexes. Why?" says:
"However, LIMIT combined with ORDER BY often will use
an index because only a small portion of the table is
returned. In fact, though MAX() and
--- John Meinel <[EMAIL PROTECTED]> escribió:
> Jaime Casanova wrote:
> [...]
> >>
> >>I'm not sure. They all return the same
> information.
> >
> >
> > of course, both queries will return the same but
> > that's just because you forced it.
> >
> > LIMIT and DISTINCT are different things so th
Jaime Casanova wrote:
[...]
I'm not sure. They all return the same information.
of course, both queries will return the same but
that's just because you forced it.
LIMIT and DISTINCT are different things so they behave
and are plenned different.
What's also weird is stuff like:
SELECT DISTINCT(NU
--- John Meinel <[EMAIL PROTECTED]> escribió:
> Curt Sampson wrote:
> > On Sun, 24 Oct 2004, John Meinel wrote:
> >
> >
> >>I was looking into another problem, and I found
> something that surprised
> >>me. If I'm doing "SELECT * FROM mytable WHERE col
> = 'myval' LIMIT 1.".
> >>Now "col" is in
Curt Sampson wrote:
On Sun, 24 Oct 2004, John Meinel wrote:
I was looking into another problem, and I found something that surprised
me. If I'm doing "SELECT * FROM mytable WHERE col = 'myval' LIMIT 1.".
Now "col" is indexed...
The real purpose of this query is to check to see if a value exists in
On Mon, 2004-10-25 at 17:17, Curt Sampson wrote:
> When you select all the columns, you're going to force it to go to the
> table. If you select only the indexed column, it ought to be able to use
> just the index, and never read the table at all.
Perhaps in other database systems, but not in Post
On Sun, 24 Oct 2004, John Meinel wrote:
> I was looking into another problem, and I found something that surprised
> me. If I'm doing "SELECT * FROM mytable WHERE col = 'myval' LIMIT 1.".
> Now "col" is indexed...
> The real purpose of this query is to check to see if a value exists in
> the colum
Tom Lane wrote:
John Meinel <[EMAIL PROTECTED]> writes:
I was looking into another problem, and I found something that surprised
me. If I'm doing "SELECT * FROM mytable WHERE col = 'myval' LIMIT 1.".
Now "col" is indexed, by mytable has 500,000 rows, and 'myval' occurs
maybe 100,000 times. Withou
John Meinel <[EMAIL PROTECTED]> writes:
> I was looking into another problem, and I found something that surprised
> me. If I'm doing "SELECT * FROM mytable WHERE col = 'myval' LIMIT 1.".
> Now "col" is indexed, by mytable has 500,000 rows, and 'myval' occurs
> maybe 100,000 times. Without the LI
I was looking into another problem, and I found something that surprised
me. If I'm doing "SELECT * FROM mytable WHERE col = 'myval' LIMIT 1.".
Now "col" is indexed, by mytable has 500,000 rows, and 'myval' occurs
maybe 100,000 times. Without the LIMIT, this query should definitely do
a sequenti
13 matches
Mail list logo
