On Fri, 21 May 2010, Richard Yen wrote:
Any ideas why the query planner chooses a different query plan when using
prepared statements?
This is a FAQ. Preparing a statement makes Postgres create a plan, without
knowing the values that you will plug in, so it will not be as optimal as
if the v
On Fri, May 21, 2010 at 4:53 PM, Richard Yen wrote:
> Any ideas why the query planner chooses a different query plan when using
> prepared statements?
A prepared plan is the best one the planner can come up with *in
general* for the query in question. If the distribution of the values
you're qu
Hi everyone,
I use DBD::Pg to interface with our 8.4.2 database, but for a particular query,
performance is horrible. I'm assuming that the behavior of $dbh->prepare is as
if I did PREPARE foo AS (query), so I did an explain analyze in the commandline:
> db_alpha=# prepare foo6 as (SELECT me.id
* Yeb Havinga (yebhavi...@gmail.com) wrote:
>> Normalizing by date parts was fast. Partitioning the tables by year
>> won't do much good -- users will probably choose 1900 to 2009,
>> predominately.
> Ok, in that case it is a bad idea.
Yeah, now that I understand what the user actually wants,
Regarding the leap year problem, you might consider creating a modified day
of year field, which always assumes that the year contains a leap day. Then
a given number always resolves to a given date, regardless of year. If you
then partition (or index) on that field, then you may get a benefit.
David Jarvis wrote:
Hi, Yeb.
This is starting to go back to the design I used with MySQL:
* YEAR_REF - Has year and station
* MONTH_REF - Has month, category, and yea referencer
* MEASUREMENT - Has month reference, amount, and day
Normalizing by date parts was fast. Partitioning th
Matthew Wakeling wrote:
On Fri, 21 May 2010, Yeb Havinga wrote:
For time based data I would for sure go for year based indexing.
On the contrary, most of the queries seem to be over many years, but
rather restricting on the time of year. Therefore, partitioning by
month or some other per-yea
Hi, Yeb.
This is starting to go back to the design I used with MySQL:
- YEAR_REF - Has year and station
- MONTH_REF - Has month, category, and yea referencer
- MEASUREMENT - Has month reference, amount, and day
Normalizing by date parts was fast. Partitioning the tables by year won't do
On Fri, 21 May 2010, Yeb Havinga wrote:
For time based data I would for sure go for year based indexing.
On the contrary, most of the queries seem to be over many years, but
rather restricting on the time of year. Therefore, partitioning by month
or some other per-year method would seem sensi
Scott Marlowe pisze:
Is one connecting via SSL? Is this a simple flat switched network, or
are these machines on different segments connected via routers?
SSL is disabled.
It is switched network, all tested computers are in the same segment.
Finally I have switched the production database f
There is a thing that might lead to confusion in the previous post:
create or replace function yearmod(int) RETURNS int
as 'select (($1 >> 2) %32);'
language sql
immutable
strict;
is equivalent with
create or replace function yearmod(int) RETURNS int
as 'select (($1 / 4) %32);'
language sql
imm
David Jarvis wrote:
Also, you're trying to do constraint_exclusion, but have you made sure
that it's turned on? And have you made sure that those
constraints are
really the right ones and that they make sense? You're using a
bunch of
extract()'s there too, why not just
12 matches
Mail list logo
