Mike Winter <[EMAIL PROTECTED]> writes:
> Basically, queries of the form SELECT FROM WHERE IN
> () take forever for high numbers of rows in the IN clause.
> We've done timing on 7.3 and 7.4b and there is no speed improvement on
> these queries.
> Does anyone know what the status of this bug is?
On Fri, Aug 22, 2003 at 08:50:15AM -0400, Tom Lane wrote:
> Bertrand Petit <[EMAIL PROTECTED]> writes:
> > On Wed, Aug 20, 2003 at 04:32:19PM -0400, Tom Lane wrote:
> >> against actual elapsed time (cf psql's \timing option) would tell.
>
> > What is measured by the \timing option?
>
> Elapse
Bertrand Petit <[EMAIL PROTECTED]> writes:
> On Wed, Aug 20, 2003 at 04:32:19PM -0400, Tom Lane wrote:
>> against actual elapsed time (cf psql's \timing option) would tell.
> What is measured by the \timing option?
Elapsed time ... as seen by the client, of course.
> The figures reported
>
> What is measured by the \timing option? The figures reported
> are slightly larger than those loged when the log_duration parameter
> is true.
The time of the psql client. It will include round trip activity
including network overhead.
signature.asc
Description: This is a digitally sign
On Wed, Aug 20, 2003 at 04:32:19PM -0400, Tom Lane wrote:
>
> against actual elapsed time (cf psql's \timing option) would tell.
What is measured by the \timing option? The figures reported
are slightly larger than those loged when the log_duration parameter
is true.
=> select count(*) fr
On Thu, 21 Aug 2003, Dani Oderbolz wrote:
> Stephan Szabo wrote:
>
> >On Wed, 20 Aug 2003, Rod Taylor wrote:
> >...
> >
> >
> >>Is the temp table version any faster? I realize it has a higher limit
> >>to the number of items you can have in the list.
> >>
> >>
> >
> >Within the scope of the new h
Stephan Szabo wrote:
On Wed, 20 Aug 2003, Rod Taylor wrote:
...
Is the temp table version any faster? I realize it has a higher limit
to the number of items you can have in the list.
Within the scope of the new hashed IN stuff I believe so in at least some
cases. I have a few million row
On Wed, 20 Aug 2003, Stephan Szabo wrote:
>
> On Wed, 20 Aug 2003, Rod Taylor wrote:
>
> > > Thanks, Stephan. I was really hoping that the IN(valuelist) was going to
> > > be changed at the same time, because it really is unusable for anything
> > > over a couple of thousand values.
> >
> > Chang
On Wed, 20 Aug 2003, Rod Taylor wrote:
> On Wed, 2003-08-20 at 17:41, Stephan Szabo wrote:
> > On Wed, 20 Aug 2003, Rod Taylor wrote:
> >
> > > > Thanks, Stephan. I was really hoping that the IN(valuelist) was going to
> > > > be changed at the same time, because it really is unusable for anythi
On Wed, 2003-08-20 at 17:41, Stephan Szabo wrote:
> On Wed, 20 Aug 2003, Rod Taylor wrote:
>
> > > Thanks, Stephan. I was really hoping that the IN(valuelist) was going to
> > > be changed at the same time, because it really is unusable for anything
> > > over a couple of thousand values.
> >
> >
Mike Winter <[EMAIL PROTECTED]> writes:
> MySQL does queries of this type orders of magnitudes faster than Postgres
> on large value lists, although I have no specific algorithmic solutions to
> offer for how to make it faster.
How large is "large", and what plan type are you getting (seq scan or
Mike Winter wrote:
On Wed, 20 Aug 2003, Rod Taylor wrote:
Ensure your IN list is unique. You might find better times by through
an indexed temp table.
That is what I ended up doing, but it's not a very elegant solution.
MySQL does queries of this type orders of magnitudes faster than Postgres
on
On Wed, 20 Aug 2003, Rod Taylor wrote:
> Ensure your IN list is unique. You might find better times by through
> an indexed temp table.
That is what I ended up doing, but it's not a very elegant solution.
MySQL does queries of this type orders of magnitudes faster than Postgres
on large value li
On Wed, 20 Aug 2003, Rod Taylor wrote:
> > Thanks, Stephan. I was really hoping that the IN(valuelist) was going to
> > be changed at the same time, because it really is unusable for anything
> > over a couple of thousand values.
>
> Changed to do what?
One possibility might be to act as if the
Ensure your IN list is unique. You might find better times by through
an indexed temp table.
On Wed, 2003-08-20 at 16:32, Mike Winter wrote:
> I'm sure many on this list are sick of hearing about this problem, but it
> was on the fix list for 7.4, but doesn't appear to have been changed.
>
> You
> Thanks, Stephan. I was really hoping that the IN(valuelist) was going to
> be changed at the same time, because it really is unusable for anything
> over a couple of thousand values.
Changed to do what?
I suppose that the ability to combine several index scans via a bitmap
would help to linear
On Wed, 20 Aug 2003, Stephan Szabo wrote:
>
> On Wed, 20 Aug 2003, Mike Winter wrote:
>
> > I'm sure many on this list are sick of hearing about this problem, but it
> > was on the fix list for 7.4, but doesn't appear to have been changed.
>
> IN (subselect) was changed for 7.4 (although I'm not s
On Wed, 20 Aug 2003, Mike Winter wrote:
> I'm sure many on this list are sick of hearing about this problem, but it
> was on the fix list for 7.4, but doesn't appear to have been changed.
IN (subselect) was changed for 7.4 (although I'm not sure of the list
mentions the difference). I don't know
I'm sure many on this list are sick of hearing about this problem, but it
was on the fix list for 7.4, but doesn't appear to have been changed.
You can see one of the many threads on the problem at:
http://archives.postgresql.org/pgsql-sql/2003-05/msg00352.php
Basically, queries of the form SELEC
19 matches
Mail list logo
