On Mon, Oct 12, 2009 at 10:14 AM, Michal Szymanski wrote:
> We have performance problem with query on partitioned table when query
> use order by and we want to use first/last rows from result set.
> More detail description:
> We have big table where each row is one telephone call (CDR).
> Definit
On Fri, Oct 16, 2009 at 5:12 PM, miller_2555
wrote:
> [...snip...] attempted to set the `join_collapse_limit` to '1' [...]
That seems like an odd thing to do - why did you do this? What
happens if you don't?
I have never seen anything like the bizarrely large row estimates that
you have here.
Robert Haas writes:
> It's probably true that in MOST of the cases where this comes up, the
> subquery can be flattened, from_collapse_limit permitting. But I
> think there are other cases, too.
Right ... and from_collapse_limit is not relevant here; only the form of
the subquery is. So I'd sur
On Sun, Oct 18, 2009 at 4:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Oct 18, 2009 at 1:59 PM, Jeff Janes wrote:
>>> Even if country.id is a primary or unique key?
>
>> Well, we currently don't have any logic for making inferences based on
>> unique constraints.
>
> Huh?
> http://arc
Robert Haas writes:
> On Sun, Oct 18, 2009 at 1:59 PM, Jeff Janes wrote:
>> Even if country.id is a primary or unique key?
> Well, we currently don't have any logic for making inferences based on
> unique constraints.
Huh?
http://archives.postgresql.org/pgsql-committers/2009-09/msg00159.php
Ad
On Sun, Oct 18, 2009 at 1:59 PM, Jeff Janes wrote:
> On Sun, Oct 18, 2009 at 10:35 AM, Tim Landscheidt
> wrote:
>> Daniel Migowski wrote:
>>
>>> I have a very common example which would illustrate the
>>> above problem a bit more. Guess the following view on a
>>> company table, which references
Jesper Krogh writes:
> Tom Lane wrote:
>> ... There's something strange about your tsvector index. Maybe
>> it's really huge because the documents are huge?
> huge is a relative term, but length(ts_vector(body)) is about 200 for
> each document. Is that huge?
It's bigger than the toy example I
Tom Lane wrote:
> Jesper Krogh writes:
>> "commonterm" matches 37K of the 50K documents (majority), but the query
>> plan is "odd" in my eyes.
>
>> * Why does it mis-guess the cost of a Seq Scan on textbody so much?
>
> The cost looks about right to me. The cost units are not milliseconds.
>
>
Jesper Krogh writes:
> "commonterm" matches 37K of the 50K documents (majority), but the query
> plan is "odd" in my eyes.
> * Why does it mis-guess the cost of a Seq Scan on textbody so much?
The cost looks about right to me. The cost units are not milliseconds.
> * Why doesn't it use the ind
On Sun, Oct 18, 2009 at 10:35 AM, Tim Landscheidt
wrote:
> Daniel Migowski wrote:
>
>> I have a very common example which would illustrate the
>> above problem a bit more. Guess the following view on a
>> company table, which references the country of that company
>> in another table. The view it
Daniel Migowski wrote:
> I have a very common example which would illustrate the
> above problem a bit more. Guess the following view on a
> company table, which references the country of that company
> in another table. The view itself just returns the
> company-id and the country-name,
>cr
Hi.
I'm currently testing out PostgreSQL's Full Text Search capabillities.
We're currenly using Xapian, it has some nice features and some
drawbacks (sorting), so it is especially this area I'm investigating.
I've loaded the database with 50K documents, and the table definition
is:
ftstest=# \d
Daniel Migowski writes:
> I have a very common example which would illustrate the above problem a
> bit more.
This is (a) still handwaving, not a testable example, and (b) unrelated
to the question at hand, because the suggested view is flattenable.
regards, tom lane
--
The actual data returned is a tiny fraction of the total table volume.
Is there a way to force an index scan on the partitions in a
guaranteed manner without resorting to re-writing queries with the
union all on partitions.
Thank you
Sriram
On Wed, Oct 14, 2009 at 10:15 PM, Tom Lane wrote:
> A
I have a very common example which would illustrate the above problem a
bit more. Guess the following view on a company table, which references
the country of that company in another table. The view itself just
returns the company-id and the country-name,
create view companys_and_countries
This seems like a pretty major weakness in PostgreSQL partitioning. I
have essentially settled on not being able to do queries against the
parent table when I want to order the results. Going to have to use a
Hibernate interceptor or something similar to rewrite the statements so
they hit spe
16 matches
Mail list logo
