Josh Berkus <[EMAIL PROTECTED]> writes:
> The fact that the estimator knows that the LIMIT is pointless because there
> are less rows in the subselect than the LIMIT will return is not something we
> want to count on; sometimes the estimator has innaccurate information.
However, when the estimato
Hi,
I have two similar tables in a database, one stores persons and the
other stores telephones. They have a similar number of records (around
70.000), but a indexed search on the persons' table is way faster than
in the telephones' table. I'm sending the explains atacched, and I
believe that the
On Sat, Dec 11, 2004 at 03:32:13PM +0100, Steinar H. Gunderson wrote:
> On Sat, Dec 11, 2004 at 03:17:13PM +0100, Tomas Skäre wrote:
> > select c.* from cjm_object c
> > inner join
> > (select max(timestamp) as timestamp,objectid,field from cjm_object
> >group by objectid,field) t
> > usin
On Fri, 10 Dec 2004 21:40:18 -0800, Josh Berkus <[EMAIL PROTECTED]> wrote:
> Mike,
> The fact that the estimator knows that the LIMIT is pointless because there
> are less rows in the subselect than the LIMIT will return is not something we
> want to count on; sometimes the estimator has innaccurat
On Sat, Dec 11, 2004 at 03:17:13PM +0100, Tomas Skäre wrote:
> select c.* from cjm_object c
> inner join
> (select max(timestamp) as timestamp,objectid,field from cjm_object
>group by objectid,field) t
> using(timestamp,objectid,field)
> where 1=1 and data is not null
> order by objectid
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Fri, 10 Dec 2004, Tomas [iso-8859-1] Skäre wrote:
>
> > I have a table that looks like this:
> >
> > Table "public.cjm_object"
> > Column | Type| Modifiers
> > ---+---+---
> > timestamp | bi
On Wed, Dec 08, 2004 at 10:42:19AM +0800, Christopher Kings-Lynne wrote:
> Why would an INSERT ever be really slow? This is what I see a lot of in
> our site logs:
>
> Dec 5 15:57:48 marshall postgres[19599]: [3-1] LOG: duration:
> 13265.492 ms statement: INSERT INTO users_sessions (sid, cob
Mike,
> I'm using the fact that Postgres can elevate a subselect-join to a
> simple join when there are no aggregates involved and I think I
> remember there has been some work recently on elevating subselects
> that contain a LIMIT, so I went back and ran the plans without the
> LIMITs to see wha
