Decibel! wrote:
> On Aug 15, 2007, at 2:11 PM, Gregory Stark wrote:
>> "Decibel!" <[EMAIL PROTECTED]> writes:
>>> On Wed, Aug 15, 2007 at 01:26:02PM -0400, Steve Madsen wrote:
On Aug 15, 2007, at 11:52 AM, Decibel! wrote:
> I can't really think of a case where a seqscan wouldn't return all
On Aug 15, 2007, at 2:11 PM, Gregory Stark wrote:
"Decibel!" <[EMAIL PROTECTED]> writes:
On Wed, Aug 15, 2007 at 01:26:02PM -0400, Steve Madsen wrote:
On Aug 15, 2007, at 11:52 AM, Decibel! wrote:
I can't really think of a case where a seqscan wouldn't return
all the
rows in the table... tha
"Decibel!" <[EMAIL PROTECTED]> writes:
> On Wed, Aug 15, 2007 at 01:26:02PM -0400, Steve Madsen wrote:
>> On Aug 15, 2007, at 11:52 AM, Decibel! wrote:
>> >I can't really think of a case where a seqscan wouldn't return all the
>> >rows in the table... that's what it's meant to do.
LIMIT
--
Gr
On Wed, Aug 15, 2007 at 01:26:02PM -0400, Steve Madsen wrote:
> On Aug 15, 2007, at 11:52 AM, Decibel! wrote:
> >I can't really think of a case where a seqscan wouldn't return all the
> >rows in the table... that's what it's meant to do.
>
> Isn't a sequential scan the only option if an appropriat
On Aug 15, 2007, at 11:52 AM, Decibel! wrote:
I can't really think of a case where a seqscan wouldn't return all the
rows in the table... that's what it's meant to do.
Isn't a sequential scan the only option if an appropriate index does
not exist? E.g., for a query with a WHERE clause, but n
On Thu, Aug 09, 2007 at 09:14:55PM -0400, Steve Madsen wrote:
> On Aug 8, 2007, at 6:08 PM, Decibel! wrote:
> >Something else I like to look at is pg_stat_all_tables seq_scan and
> >seq_tup_read. If seq_scan is a large number and seq_tup_read/
> >seq_scan is
> >also large, that indicates that you
On Aug 8, 2007, at 6:08 PM, Decibel! wrote:
Something else I like to look at is pg_stat_all_tables seq_scan and
seq_tup_read. If seq_scan is a large number and seq_tup_read/
seq_scan is
also large, that indicates that you could use an index on that table.
If seq_tup_read / seq_scan is large r
On Wed, Aug 08, 2007 at 11:01:13AM -0400, Steve Madsen wrote:
> Can anyone provide a brief overview of how to go about interpreting
> the information generated by the statistics collector? I've looked
> around and can't find old mailing list messages or anything in the
> manual beyond the ba
Can anyone provide a brief overview of how to go about interpreting
the information generated by the statistics collector? I've looked
around and can't find old mailing list messages or anything in the
manual beyond the basics of how to query the statistics.
Cache hit rates are easy to com
