On Tue, Nov 16, 2010 at 05:28:19PM +0100, Harald Fuchs wrote:
> In article <4ce2688b.2050...@tweakers.net>,
> Arjen van der Meijden writes:
>
> > On 16-11-2010 11:50, Louis-David Mitterrand wrote:
> >> I have to collect lots of prices from web sites and keep track
On Tue, Nov 16, 2010 at 11:35:24AM -0500, Chris Browne wrote:
> vindex+lists-pgsql-performa...@apartia.org (Louis-David Mitterrand)
> writes:
> > I have to collect lots of prices from web sites and keep track of their
> > changes. What is the best option?
> >
> >
On Tue, Nov 16, 2010 at 12:18:35PM +0100, Arjen van der Meijden wrote:
> On 16-11-2010 11:50, Louis-David Mitterrand wrote:
> >I have to collect lots of prices from web sites and keep track of their
> >changes. What is the best option?
> >
> >1) one 'price' row
On Tue, Nov 16, 2010 at 12:03:29PM +0100, Pavel Stehule wrote:
> Hello
>
> my opinion:
>
> @1 can be faster for access to last items with index
> @2 can be more effective about data files length allocation
Hi Pavel,
What is "data files length allocation" ?
--
Sent via pgsql-performance mailin
Hi,
I have to collect lots of prices from web sites and keep track of their
changes. What is the best option?
1) one 'price' row per price change:
create table price (
id_price primary key,
id_product integer references product,
price inte
Hi,
On a hunch I removed two (legacy) WHERE conditions from the following
query I obtained a 158x speed improvement. Yet these condiditions do not
filter anything. Does that make any sense?
The EXPLAIN ANALYSE output is attached with, first the fast version and
then the slow one.
I'd like to und
