On Tue, Jun 2, 2009 at 9:52 AM, Tom Lane wrote:
>
> delete from pg_statistic
> where (starelid, staattnum) in
> (select attrelid, attnum from pg_attribute
> where attrelid = 'my_relation'::regclass and attname = 'my_attribute');
>
> regclass knows about schemas and search paths, so stuff like
r the specified column in the specified table.
|>ouglas
On Mon, Jun 1, 2009 at 2:20 PM, Douglas Alan wrote:
> I'd like to manually alter the statistics for a column, as for the column
> in question the statistics are causing Postgres to do the wrong thing for my
> purposes. (I.e., a S
I'd like to manually alter the statistics for a column, as for the column in
question the statistics are causing Postgres to do the wrong thing for my
purposes. (I.e., a Seq Scan, rather than an Index Scan.) If someone can
tell me how to achieve this, I would quite grateful.
Thanks!
|>ouglas
P.
Scott Marlowe wrote:
> Douglas Alan wrote:
>> Okay -- no problem:
>>
>>set enable_seqscan = on;
>>explain analyze select * from maindb_astobject
>>where survey_id = 2
>>limit 1000;
>>
>>"Limit (cost=0.00..48.03 rows=1
Scott Marlowe wrote:
> Douglas Alan wrote:
>> I'm worried that turning off seqscan would distort other queries.
>> (Remember, I don't have control of the individual queries. The
>> user of the application can specify all sorts of queries, and
>> there'
On Thu, May 28, 2009 at 5:52 PM, Simon Riggs wrote:
>
> On Thu, 2009-05-28 at 15:03 -0400, Douglas Alan wrote:
>
> > The application in question is a kind of data warehousing thing (of
> > astronomical stars), and there's an ORM in the middle, so it's not
&
On Thu, May 28, 2009 at 10:41 AM, Scott Marlowe
wrote:
> Note that in the OPs case I'd probably try testing things like turning
> off seqscan, or lowering random_page_cost. I'd also look at
> clustering on the index for the field you're selecting on.
I'm worried that turning off seqscan would d
On Thu, May 28, 2009 at 10:24 AM, Scott Marlowe wrote:
> OTOH, if you've got it all sussed out, then ignore the request for more
> information.
I don't *know* if I have it "all sussed out", but I *do* know why
Postgres is doing what it is doing in this particular case. It's
assuming that the
On Thu, May 28, 2009 at 4:14 AM, Simon Riggs wrote:
> Partition the table, then scan the correct partition.
If I do that, will Postgres figure out the "right thing" to do if the
parent table is queried instead? Also, what are the performance
implications then for doing queries that span all the
On Wed, May 27, 2009 at 8:54 PM, Jeff Davis wrote:
> If you're putting a LIMIT on it, why does it return millions of results?
>
It *doesn't* return millions of results with the LIMIT on it. It just does
a sequential scan of the table and doesn't find any results until it gets to
the last quart
We have a very large table (150 million rows) where the rows are not in a
random order. Some common queries will have millions of results, and this
of course is slow. For an interactive interface to the database, we want to
put a limit on all queries so that queries will return quickly even if th
11 matches
Mail list logo
