"Janek Sendrowski" writes:
> Sorry, I still wanted to add following link:
> http://www.sai.msu.su/~megera/postgres/talks/Full-text%20search%20in%20PostgreSQL%20in%20milliseconds-extended-version.pdf
Oh ... well, that's not Postgres documentation; that's Oleg and Alexander
giving a paper about so
Mack Talcott writes:
> The pattern I am seeing is that postgres processes keep growing in
> shared (this makes sense as they access more of the shared memory, as
> you've pointed out) but also process-specific memory as they run more
> queries. The largest ones are using around 300mb of process-s
2013/12/11 Jeff Janes
> On Tuesday, December 10, 2013, jacket41142 wrote:
>
>> Thanks very much.
>>
>> I think another problem is that the cost estimation isn't good enough to
>> reflex real cost. Since we can see, from "explain analyze ...",
>> count(distinct ...) has smallest cost between the o
On Tue, Dec 10, 2013 at 8:54 PM, Tom Lane wrote:
> Mack Talcott writes:
>> I am trying to debug some shared memory issues with Postgres 9.3.1 and
>> CentOS release 6.3 (Final). I have a database machine that probably has
>> some misconfigured shared memory settings. It's getting into 2+ GB of
>
Sorry, I still wanted to add following link:
http://www.sai.msu.su/~megera/postgres/talks/Full-text%20search%20in%20PostgreSQL%20in%20milliseconds-extended-version.pdf
On page 6 you can see the first example:
"postgres=# explain analyze
SELECT docid, ts_rank(text_vector, to_tsquery('english', 'ti
Craig James writes:
> A GIST is a tree, but there's no notion of ">" or "<", only yes/no at each
> tree branch. In this regard a GIST index is more like a hash table. You
> can't use a hash table to sort. It doesn't make sense.
Recent versions of PG do allow GIST indexes to be used to satisfy
On Wed, Dec 11, 2013 at 2:29 PM, Janek Sendrowski wrote:
> Hi,
>
> How can I use this ORDER BY using index feature presented in this
> implementation.
> It doesn't seem to be in use, when I have a look in my query plan.
> It still does an cost intensive Bitmap Heap Scan and a Bitmap Index scan.
>
"Janek Sendrowski" writes:
> How can I use this ORDER BY using index feature presented in this
> implementation.
> It doesn't seem to be in use, when I have a look in my query plan.
> It still does an cost intensive Bitmap Heap Scan and a Bitmap Index scan.
> I also can't find the "><" operator i
[Sorry, this previous mail was HTML-foramted]
Hi,
How can I use this ORDER BY using index feature presented in this
implementation.
It doesn't seem to be in use, when I have a look in my query plan.
It still does an cost intensive Bitmap Heap Scan and a Bitmap Index scan.
I also can't find the
Hi,
How can I use this ORDER BY using index feature presented in this implementation.
It doesn't seem to be in use, when I have a look in my query plan.
It still does an cost intensive Bitmap Heap Scan and a Bitmap Index scan.
I also can't find the "><" operator in any introduction of the ts
I have a slow query (I think) that doesn't appear to be using an index for some
reason. I've tried writing the query in various ways, but have so far not had
any luck. Interestingly, the query plans are almost identical even when trying
different variations. It appears to spend half the time
11 matches
Mail list logo
