--- Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Sorry there isn't a simple solution.
> >
> > But there is: make an index with the column order (b,c,a).
>
> Oh, yea, right. If he puts the columns he is doing a straight equals
> c
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Sorry there isn't a simple solution.
>
> But there is: make an index with the column order (b,c,a).
Oh, yea, right. If he puts the columns he is doing a straight equals
comparison first, the 'a' comparison will work fine. Great.
-
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Sorry there isn't a simple solution.
But there is: make an index with the column order (b,c,a).
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
ow wrote:
> --- Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Strange 30 records takes 30x the time than one record. Can you run
> > ANALYZE and send us an EXPLAIN of the query to make sure it hasn't
> > changed?
> >
>
> explain analyze select * from Test
> where a >= '2002-06-18'
> and a <= '2
--- Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Strange 30 records takes 30x the time than one record. Can you run
> ANALYZE and send us an EXPLAIN of the query to make sure it hasn't
> changed?
>
explain analyze select * from Test
where a >= '2002-06-18'
and a <= '2002-07-18'
and b = 5
and
On Mon, 10 Nov 2003, ow wrote:
> --- Stephan Szabo <[EMAIL PROTECTED]> wrote:
> > I'm not sure that AK_abc is the best index for check a range on a and
> > single values on b and c. I'd think that something like an index
> > on (b,c,a) would probably be better for this purpose (without doing any
ow wrote:
> Hi,
>
> I tried CLUSTER and it did improve performance, somewhat. The query against
> "clustered" table performs about five (5) times better than the same table but
> "non-clustered". However, even after that table was clustered, the difference
> in performance between single record qu
--- Stephan Szabo <[EMAIL PROTECTED]> wrote:
> I'm not sure that AK_abc is the best index for check a range on a and
> single values on b and c. I'd think that something like an index
> on (b,c,a) would probably be better for this purpose (without doing any
> testing ;) ).
That would not work fo
Hi,
I tried CLUSTER and it did improve performance, somewhat. The query against
"clustered" table performs about five (5) times better than the same table but
"non-clustered". However, even after that table was clustered, the difference
in performance between single record query and range query is
On Sat, 8 Nov 2003, ow wrote:
> Postgresql 7.4.rc1 on i686 pc linux compiled by gcc 2.06.
> All configuration settings are default.
>
>
> Hi,
>
> Trying to find a way to improve range query performance.
>
> The table Test has about 30 million records.
>
> -- DLong, Dtimestamp, Dint, etc are domain
Try CLUSTER --- that usually helps with index scans on ranges.
---
ow wrote:
> Postgresql 7.4.rc1 on i686 pc linux compiled by gcc 2.06.
> All configuration settings are default.
>
>
> Hi,
>
> Trying to find a way to impr
Postgresql 7.4.rc1 on i686 pc linux compiled by gcc 2.06.
All configuration settings are default.
Hi,
Trying to find a way to improve range query performance.
The table Test has about 30 million records.
-- DLong, Dtimestamp, Dint, etc are domains of the respective types.
create table Test (
i
12 matches
Mail list logo
