incent
>
> > -Message d'origine-
> > De : pgsql-general-ow...@postgresql.org
> > [mailto:pgsql-general-ow...@postgresql.org] De la part de Reg
> > Me Please
> > Envoyé : mardi 30 décembre 2008 17:09
> > À : Scott Marlowe
> > Cc : Scott Ri
e; pgsql-general@postgresql.org
> Objet : Re: [GENERAL] [PGSQL 8.3.5] Use of a partial indexes
>
> Here it comes:
>
> -- DDL
>
> CREATE TABLE gm_t_movimenti_magazzini
> (
> gm_movi_unic INT8 NOT NULL REFERENCES gm_t_movimenti,
> gm_moti_unic TEXT NOT NULL
Here it comes:
-- DDL
CREATE TABLE gm_t_movimenti_magazzini
(
gm_movi_unic INT8 NOT NULL REFERENCES gm_t_movimenti,
gm_moti_unic TEXT NOT NULL REFERENCES gm_t_movimenti_tipi,
ap_prod_unic INT8 NOT NULL REFERENCES ap_t_prodotti,
gm_maga_unic TEXT NOT NULL REFERENCES gm_t_magazzini,
gm_mo
Reg Me Please wrote:
Only one question remains in my mind:
why the planner is not using the partial index?
The partial index is covering 2 predicates out of the 3 used in the where
condition. Actually there is a boolean flag (to exclude "disabled" rows),
a timestamp (for row age) and an int
On Tue, Dec 30, 2008 at 2:02 AM, Reg Me Please wrote:
> Only one question remains in my mind:
>
> why the planner is not using the partial index?
>
> The partial index is covering 2 predicates out of the 3 used in the where
> condition. Actually there is a boolean flag (to exclude "disabled" rows)
Only one question remains in my mind:
why the planner is not using the partial index?
The partial index is covering 2 predicates out of the 3 used in the where
condition. Actually there is a boolean flag (to exclude "disabled" rows),
a timestamp (for row age) and an int8 (a FK to another table).
On Mon, Dec 29, 2008 at 9:28 AM, Scott Ribe wrote:
>> voila! cache dumped.
>
> What about read caches in the disk devices themselves?
Given that most drives have caches that are in the 16 to 32Meg range,
I doubt it makes a big difference. But you can always just dd a file
both ways that are 100
> voila! cache dumped.
What about read caches in the disk devices themselves?
--
Scott Ribe
scott_r...@killerbytes.com
http://www.killerbytes.com/
(303) 722-0567 voice
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.post
On Mon, Dec 29, 2008 at 8:36 AM, Scott Ribe wrote:
> Creating the partial index reads rows, and the pages are left in the disk
> cache. The only way to do proper comparisons is to reboot between trials in
> order to compare queries with cold caches, or use the latter of multiple
> runs in order to
> The WHERE condition can be divided into a "slowly changing" part and in
> a "random" one. The random part is the one I change at every query to avoid
> result caching.
The first query will leave in cache at least many of the index pages needed
by the second query, and likely actual rows needed b
On Mon, Dec 29, 2008 at 7:41 AM, Reg Me Please wrote:
> Hi.
>
> The WHERE condition can be divided into a "slowly changing" part and in
> a "random" one. The random part is the one I change at every query to avoid
> result caching.
>
> The planner seems to be smart enough to "learn" while working
Hi.
The WHERE condition can be divided into a "slowly changing" part and in
a "random" one. The random part is the one I change at every query to avoid
result caching.
The planner seems to be smart enough to "learn" while working but then
I should see a change in the EXPLAIN output, which never h
Not sure if this applies to your case, but I've seen cases where an initial run
of a particular query is a lot slower than subsequent runs even though no
changes were made between the two. I suspect that the initial run did all the
disk IO needed to get the data (slow), and that the subsequent
13 matches
Mail list logo
