On Mon, Apr 26, 2010 at 5:24 PM, Anj Adu wrote:
> I have a 16G box and tmpfs is configured to use 8G for tmpfs .
>
> Is a lot of memory being wasted that can be used for Postgres ? (I am
> not seeing any performance issues, but I am not clear how Linux uses
> the tmpfs and how Postgres would be af
I have a 16G box and tmpfs is configured to use 8G for tmpfs .
Is a lot of memory being wasted that can be used for Postgres ? (I am
not seeing any performance issues, but I am not clear how Linux uses
the tmpfs and how Postgres would be affected by the reduction in
memory)
Sriram
--
Sent via p
Rick wrote:
> So, in a large table, the scale_factor is the dominant term. In a
> small
> table, the threshold is the dominant term. But both are taken into
> account.
Correct.
> The default values are set for small tables; it is not being run for
> large tables.
So decrease the scale factor an
=?KOI8-R?B?68/Sz9TLz9cg4czFy9PBzsTS?= writes:
> So PostgreSQL planner can produce the plan I need but it doesn't produce
> this plan when I specify particular second ordering column.
Well, no, because that plan wouldn't produce the specified ordering;
or at least it would be a lucky coincidence i
Hello, everybody!
I'm using PostgreSQL 8.4.3, compiled by Visual C++ build 1400, 32-bit on
Windows XP SP3.
I use following data model for issue reproducing.
CREATE TABLE test1
(
id integer NOT NULL,
"value" double precision,
CONSTRAINT test1_pkey PRIMARY KEY (id)
);
CREATE INDEX test1_valu
On Apr 22, 2:55 pm, robertmh...@gmail.com (Robert Haas) wrote:
> On Wed, Apr 21, 2010 at 11:06 AM, Rick wrote:
> > I have a DB with small and large tables that can go up to 15G.
> > For performance benefits, it appears that analyze has much less cost
> > than vacuum, but the same benefits?
>
> Err
2010/4/26 Vlad Arkhipov :
>
>> On Thu, Apr 22, 2010 at 10:37 PM, Vlad Arkhipov
>> wrote:
>>
>>>
>>> I don't think this is just an issue with statistics, because the same
>>> problem arises when I try executing a query like this:
>>>
>>
>> I'm not sure how you think this proves that it isn't a prob