On 2011-11-30 21:58, Robert Haas wrote:
The row-count estimates look reasonably accurate, so there's some
other problem here. What do you have random_page_cost, seq_page_cost,
and effective_cache_size set to? You might try "SET
random_page_cost=2" or even "SET random_page_cost=0.5; SET
seq_page
We're trying to split the current day into hourly tables so that the
size of the indexes that are popular is much lower and therefore we can
support more rows across the day. We also are using numerics where we
could be using bigints, so we're going to also work on that to see how
much smaller we
thx a lot for your answer :)
so when a transaction is still open from a while back (according to the
transactionID), no 'new dead' tuples can be marked as re-usable space for
new rows, right? by 'new dead' i mean that for example there is a
transaction running from 10.00am(with a specific transact
MX,
> to my understanding, vacuum just marks the dead rows of a table so that from
> that point on that space would be re-used for new inserts and new updates on
> that specific table. however, if there is an open transaction, vacuum can
> only do what is described above up to the point that the o
On Mon, Nov 21, 2011 at 12:53 AM, Rauan Maemirov wrote:
> The problem has returned back, and here's the results, as you've said it's
> faster now:
>
> SET enable_seqscan=off;
> EXPLAIN ANALYZE SELECT "v"."id", "v"."title" FROM "video" AS "v"
> WHERE (v.active) AND (v.fts @@
> 'dexter:A|season:A|se
On Mon, Nov 14, 2011 at 5:22 PM, Andrew Barnham
wrote:
> I wonder, if it is possible and worthwhile, to setup the query planner to
> recognize that because of the stats I indicate above, that a sort by partnum
> is almost exactly the same as a sort by partnum+franchise. And doing a
> Index scan o
> We now found (thanks Andres and Snow-Man in #postgresql) that in our
> tests, after the indexes get too large performance drops signficantly
> and our system limps forward due to disk reads (presumably for the
> indexes). If we remove the indexes, performance for our entire sample
> test is gre
Experts,
Quick Summary: data can now be inserted very quickly via COPY + removing
indexes, but is there a design or some tricks to still allow someone to
query while the partition is still active and 'hot' ?
- Postgres 9.1
- Windows 7 (64-bit) , although this is just for the current test and
coul
