Stephan Szabo wrote:
Well, the reason I asked is to see both whether the estimates for the
various columns were somewhere near reality (if not, then you may need to
raise the statistics target for the column) which might affect whether
it'd consider using a multi-column index for the conditions and
On Tue, 8 Jul 2003, Martin Foster wrote:
> Stephan Szabo wrote:
>
> > The row estimate is high. How many rows meet the various conditions and
> > some of the combinations? And how many rows does it estimate if you do a
> > simpler query on those with explain?
> >
> > I still think some variety of
Stephan Szabo wrote:
The row estimate is high. How many rows meet the various conditions and
some of the combinations? And how many rows does it estimate if you do a
simpler query on those with explain?
I still think some variety of multi-column index to make the above index
conditions would help
On Tue, 8 Jul 2003, Martin Foster wrote:
> Stephan Szabo wrote:
> >
> >
> > I think you might get better results with some kind of multi-column index.
> > It's using the index to avoid a sort it looks like, but it's not helping
> > to find the conditions. I can't remember the correct ordering, but
Stephan Szabo wrote:
I think you might get better results with some kind of multi-column index.
It's using the index to avoid a sort it looks like, but it's not helping
to find the conditions. I can't remember the correct ordering, but maybe
(posttimestamp, realmname, postidnumber). Having separ
> Please note: I'm using Version 7.1
Upgrade to 7.3 :)
> Following everyone's advice, I increased my max_connections to 64 and
shared_buffers to 2000. However, the postmaster then started to issue me
error messages saying
>
> pg_recvbuf: unexpected EOF on client connection
That's odd. I ha
On Tue, 8 Jul 2003, Martin Foster wrote:
> As I keep looking through code to see where I can make things more
> efficient, I noticed that in some cases timestamps seem horribly
> inefficient. This leads to very long run times for certain queries.
>
> Here is an example:
>
> -- USING TIMESTAMPS
As I keep looking through code to see where I can make things more
efficient, I noticed that in some cases timestamps seem horribly
inefficient. This leads to very long run times for certain queries.
Here is an example:
-- USING TIMESTAMPS TO NARROW DOWN --
SELECT
Post.PostIDNumber,
Post.P
Hi all,
You may remember in my last report, I said that it appeared that
TCP/IP connections caused EXPLAIN ANALYSE to return (repeatably but
not consistently) slower times than when connected over UNIX domain
sockets.
This turns out to be false. We (well, Chris Browne, actually) ran
some tests
Dear All
Please note: I'm using Version 7.1
Following everyone's advice, I increased my max_connections to 64 and shared_buffers
to 2000. However, the postmaster then started to issue me error messages saying
pg_recvbuf: unexpected EOF on client connection
Help! (Needless to say I've rest
On Mon, 7 Jul 2003, Matthew Nuzum wrote:
> > A common problem is a table like this:
> >
> > create table test (info text, id int8 primary key);
> > insert into test values ('ted',1);
> > .. a few thousand more inserts;
> > vacuum full;
> > analyze;
> > select * from test where id=1;
> >
> > will
11 matches
Mail list logo
