Hi Daniel:
On Mon, May 25, 2015 at 10:03 PM, Daniel Begin wrote:
...
> Even after doing all this, I did not find any improvement in execution times
> between my original fat table and the partitioned version (sometime even
> worst). If partitioning the table has improved significantly queries r
Thank for your patience :-)
- About using PgAdmin, anecdotal problems or not, I did the whole tests again
in plain postgresql.
- About running queries once or not, Bill and Francisco both pointed out
somehow that I should run each query multiple times to get appropriate
statistics. I did it fo
Hi Daniel:
Bill Moran already pointed out some things, I more or less agree with him
On Sun, May 24, 2015 at 12:16 AM, Daniel Begin wrote:
..
> I use pgadmin_III sql window.
I'll just point from my experience. At work, more than three fourths
of the problems I've had to help my pgadmin
Hi Daniel:
On Sat, May 23, 2015 at 8:37 PM, Daniel Begin wrote:
> Following Francisco suggestion, I was able to do some tests earlier this
> morning when the partitioning process completed and all the resulting tables
> analyzed.
> Here is what I got on both the original table and its partiti
On Sat, 23 May 2015 18:16:43 -0400
Daniel Begin wrote:
> Hello Bill,
> You wrote that my testing methodology is flawed - I hope you are right!
>
> However, I am a bit confused about your comments. Yes, I did edited the name
> of the tables for clarity but if I miss the point I, I will do it a
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of melvin6925
Sent: May-23-15 15:15
To: Daniel Begin; pgsql-general@postgresql.org
Subject: Re: [GENERAL] FW: Constraint exclusion in partitions
Did you remember to set constraint_exclusion = on and reload the .conf ?
Sent via
g time) but I swear, I did not change the
times when editing table names!-)
Do you see any glitch/flaw in the procedure I am using?
Someone has an idea about the problem behind this unexpected behavior?
I really need to get much faster results with my queries on this large table
and partitioni
ject: Re: [GENERAL] FW: Constraint exclusion in partitions
Following Francisco suggestion, I was able to do some tests earlier this
morning when the partitioning process completed and all the resulting tables
analyzed.
Here is what I got on both the original table and its partitioned counter
A large portion of why you describe below is the exact opposite of my
own testing (unfortunately, I don't have the actual test results any
more because I did the tests for a former employer).
In my tests, single lookups against the same column being used to
partition improved performance in direc
] FW: Constraint exclusion in partitions
Following Francisco suggestion, I was able to do some tests earlier this
morning when the partitioning process completed and all the resulting tables
analyzed.
Here is what I got on both the original table and its partitioned counterpart
while running the
Following Francisco suggestion, I was able to do some tests earlier this
morning when the partitioning process completed and all the resulting tables
analyzed.
Here is what I got on both the original table and its partitioned counterpart
while running the same queries. I tested them only for a
Hi Daniel
On Fri, May 22, 2015 at 7:21 PM, Daniel Begin wrote:
> I have split a large table (billions of records) into multiple partitions,
> hoping the access would be faster. I used an ID to make partitions check
> (check (id >= 100 AND id < 200)…) and created over 80 tables (children) that
> a
On Fri, May 22, 2015 at 10:21 AM, Daniel Begin wrote:
> But how constraint exclusion would react with the following queries …
>
> b- Select * from parent_table where id between 2345 and 6789; --
> using a range of ids
>
Not sure...
These are constants but I'm not sure how smart the plann
13 matches
Mail list logo
