On 2/15/07, Guillaume Smet <[EMAIL PROTECTED]> wrote:
On 2/15/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> I think that the
> answer is probably "because the index is lossy for this operator,
> so it has to be checked even if the bitmap didn't become lossy".
> You'd have to check the GIST opclass de
On 2/15/07, Tom Lane <[EMAIL PROTECTED]> wrote:
I think that the
answer is probably "because the index is lossy for this operator,
so it has to be checked even if the bitmap didn't become lossy".
You'd have to check the GIST opclass definition to be sure.
Any idea on what I have to look for (if
Hello,
I'm experiencing some very unusual speed problems while executing a
particular query. Appending an empty string to one of the fields in
the query speeds up the execution by a 1000 fold. According to the
planner this alternate query is much more costly too. Here are the
EXPLAIN
Selon Richard Huxton :
> philippe wrote:
> > explain analyse
> > select count(*) from client_contact
> > left join client_company using(cli_id)
> > where (cli_mail = '[EMAIL PROTECTED]') OR
> > (lower(cli_nom) = 'xx' and zipcode = '10001');
> >
> > QUERY PLAN
> >
>
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Guillaume Smet escribió:
>> Is it normal I have no recheck cond and the index cond of Bitmap Index
>> Scan is in the filter? Is it also a consequence of the code you
>> pointed?
> It is in the filter, is it not? Having a recheck would be redundant.
Ye
Guillaume Smet escribió:
> I'm still working on my proximity query, testing PostGIS now. I
> noticed an issue with a gist index on a point which seems related to
> my previous question.
>
> I have the following in my plan:
> -> Bitmap Heap Scan on lieu l (cost=13.37..1555.69 rows=844
> width=11
On 2/14/07, Paul Ramsey <[EMAIL PROTECTED]> wrote:
You'll find that PostGIS does a pretty good job of selectivity
estimation.
So I finally have a working PostGIS and I fixed the query to use PostGIS.
The use of PostGIS is slower than the previous cube/earthdistance
approach (on a similar query
Tom,
On 2/13/07, Tom Lane <[EMAIL PROTECTED]> wrote:
It gets the right answer, yes. I'm not sure if we could safely put the
condition into the recheck instead of the filter. The particular code
I showed you has to go the direction it does, because a condition in the
filter has to be checked ev
philippe wrote:
explain analyse
select count(*) from client_contact
left join client_company using(cli_id)
where (cli_mail = '[EMAIL PROTECTED]') OR
(lower(cli_nom) = 'xx' and zipcode = '10001');
QUERY PLAN
-
Hi
I'm using posstgresql 8.1.4 on linux 2.6
shared_buffers = tested with 3000 and 1
temp_buffers = 1000
work_mem = 4096
effective_cache_size = 65536
random_page_cost = 2
I have a query which I think is anormaly slow with à 'OR'
select count(*) from client_contact
left join client_company us
> Not happening here (8.2.x, output redirected using "\o /dev/null") - are
> you sure it's not psql (or whatever client) that's using up your memory,
> as it tries to build the entire result set before sending it to
> /dev/null? Don't forget, you've got 5 copies of the columns so that
> would b
Konstantinos Krikellas wrote:
Hi,
I am using PostgreSQL for benchmarking and I study the following query:
SELECT *
FROM k10_1, k10_2, k10_3, k10_4, k10_5
WHERE k10_1.times4 = k10_2.times4
AND k10_2.times4 = k10_3.times4
AND k10_3.times4 = k10_4.times4
AND k10_4.times4 = k10_5.times4
On 2/14/07, Luke Lonergan <[EMAIL PROTECTED]> wrote:
Hi Merlin,
On 2/14/07 8:20 AM, "Merlin Moncure" <[EMAIL PROTECTED]> wrote:
> I am curious what is your take on the maximum insert performance, in
> mb/sec of large bytea columns (toasted), and how much if any greenplum
> was able to advance t
Hi,
I am using PostgreSQL for benchmarking and I study the following query:
SELECT *
FROM k10_1, k10_2, k10_3, k10_4, k10_5
WHERE k10_1.times4 = k10_2.times4
AND k10_2.times4 = k10_3.times4
AND k10_3.times4 = k10_4.times4
AND k10_4.times4 = k10_5.times4
The used schema for all the tables
14 matches
Mail list logo
