Robert Haas wrote:
On Mon, Aug 10, 2009 at 11:19 AM, Kevin Grittner
wrote:
(2) Somehow use effective_cache_size in combination with some sort of
current activity metrics to dynamically adjust random access costs.
(I know, that one's total hand-waving, but it seems to have some
possibility of b
Krade wrote:
SELECT * FROM a WHERE comment_tsv @@ plainto_tsquery('love') ORDER BY
timestamp DESC LIMIT 24 OFFSET 0;
Have you tried make the full-text condition in a subselect with "offset
0" to stop the plan reordering?
eg:
select *
from (
select * from a where comment_tsv @@ plainto_tsq
Marc Cousin wrote:
Le Thursday 16 July 2009 22:07:25, Kevin Grittner a écrit :
Marc Cousin wrote:
the hot parts of these 2 tables are extremely likely to be in the
database or linux cache (buffer hit rate was 97% in the example
provided). Moreover, the first two queries of the insert procedure
Marc Cousin wrote:
This mail contains the asked plans :
Plan 1
around 1 million records to insert, seq_page_cost 1, random_page_cost 4
-> Hash (cost=425486.72..425486.72 rows=16746972 width=92) (actual
time=23184.196..23184.196 rows=16732049 loops=1)
-> Seq Scan on
