Merlin Moncure writes:
> you can always do this:
> create index performance_creation_date_desc_idx on
> performance(creation_date desc nulls last);
> which will index optimize your sql. Interesting that 'null last'
> fools disallows index usage even when the index was created with
> nullls last
Benjamin Krajmalnik wrote:
Index Scans0
Index Tuples Read 0
Index Tuples Fetched0
Index Blocks Read 834389
Index Blocks Hit247283300
Index Size 1752 kB
Since there are no in
On Mon, Feb 14, 2011 at 5:36 AM, Pavel Stehule wrote:
> Hello
>
> 2011/2/14 dba :
>>
>>
>> create table a( address1 int,address2 int,address3 int)
>> create table b(address int[3])
>>
>> I have created two tables. In the first table i am using many fields to
>> store 3 address.
>> as well as in b
On Wed, Feb 23, 2011 at 1:27 PM, Mathieu De Zutter wrote:
> Hi all,
> Running PostgreSQL 8.4.7 (backport package from Debian Lenny).
> I have some queries that are based on views, and an engine adds a few
> clauses (like NULLS LAST). One of these queries has a performance problem.
> The simplified
Hi all,
Running PostgreSQL 8.4.7 (backport package from Debian Lenny).
I have some queries that are based on views, and an engine adds a few
clauses (like NULLS LAST). One of these queries has a performance problem.
The simplified form is this:
shs=# explain analyze select * from performance e
I am trying to clean up our schema by removing any indices which are not
being used frequently or at all.
Using pgadmin, looking at the statistics for an index, I see various
pieces of information:
Index Scans, Index Tuples Read, Index Tuples Fetched, Index Blocks Read,
and Index Blocks Hit.
On Wed, Feb 23, 2011 at 12:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> ...but that begs the question of why DROP INDEX needs an
>> AccessExclusiveLock. It probably needs such a lock *on the index* but
>> I don't see why we'd need it on the table.
>
> Some other session might be in process of
Robert Haas writes:
> ...but that begs the question of why DROP INDEX needs an
> AccessExclusiveLock. It probably needs such a lock *on the index* but
> I don't see why we'd need it on the table.
Some other session might be in process of planning a query on the table.
It would be sad if the inde
On Tue, Feb 22, 2011 at 11:21 PM, Noah Misch wrote:
> On Tue, Feb 22, 2011 at 10:18:36PM -0500, Robert Haas wrote:
>> On Wed, Feb 2, 2011 at 12:20 AM, Noah Misch wrote:
>> >> CREATE TABLE account (account_id SERIAL PRIMARY KEY, name CHARACTER
>> >> VARYING
>> >> NOT NULL);
>> >> CREATE TABLE foo
