Hello Guillaume!
Wed, 26 Aug 2009 23:59:25 +0200, you wrote:
On Wed, Aug 26, 2009 at 6:29 PM, Tom Lanet...@sss.pgh.pa.us wrote:
g...@pilotsystems.net (=?iso-8859-1?Q?Ga=EBl?= Le Mignot) writes:
So it seems it was quite wrong about estimated matching rows (192
predicted, 10222 reals).
2009/8/27 Gaël Le Mignot g...@pilotsystems.net:
The weird thing was that with the default of 100 for statistics
target, it was worse than when we moved back to 10. So I didn't try
with 1000, but I should have.
When you have so much data and a statistics target so low, you can't
Hello Guillaume!
Sun, 23 Aug 2009 14:49:05 +0200, you wrote:
Hi Gaël,
On Fri, Aug 21, 2009 at 3:37 PM, Gaël Le Mignotg...@pilotsystems.net wrote:
With 8.3 ::
Limit (cost=752.67..752.67 rows=1 width=24)
(11 rows)
With 8.4 ::
(8 rows)
Could you provide us the EXPLAIN
On Wed, Aug 26, 2009 at 6:29 PM, Tom Lanet...@sss.pgh.pa.us wrote:
g...@pilotsystems.net (=?iso-8859-1?Q?Ga=EBl?= Le Mignot) writes:
So it seems it was quite wrong about estimated matching rows (192 predicted,
10222 reals).
Yup. What's even more interesting is that it seems the real win
Hi Gaël,
On Fri, Aug 21, 2009 at 3:37 PM, Gaël Le Mignotg...@pilotsystems.net wrote:
With 8.3 ::
Limit (cost=752.67..752.67 rows=1 width=24)
(11 rows)
With 8.4 ::
(8 rows)
Could you provide us the EXPLAIN *ANALYZE* output of both plans?
From what I can see, one of the difference is
Hello,
We are using PostgreSQL to index a huge collection (570 000) of articles for a
french daily newspaper (Libération). We use massively the full text search
feature. I attach to this mail the schema of the database we use.
Overall, we have very interesting performances, except in a few
