Hello
2011/6/20 Julius Tuskenis :
> Hello,
>
> I'm sorry to write again, but as I received no answer I wonder if there is a
> better mailing list to address concerning this question? Or is there nothing
> to be done about the speed of xmlagg ?. Please let me as no answer is the
> worst answer to g
Hello,
I'm sorry to write again, but as I received no answer I wonder if there
is a better mailing list to address concerning this question? Or is
there nothing to be done about the speed of xmlagg ?. Please let me as
no answer is the worst answer to get
--
Julius Tuskenis
Programavimo s
Hi all!
Please, just look at these query explanations and try to explain why
planner does so (PostgreSQL 8.4).
There is an index on table sms (number, timestamp).
And three fast & simple queries:
=# explain analyze select max(timestamp) from sms where number='5502712';
Hi!
Thanks (you both, Samuel and Craig) for your answers!
On Sun, Jun 19, 2011 at 11:19 AM, Craig James
wrote:
> On 6/19/11 4:37 AM, Samuel Gendler wrote:
>
> On Sat, Jun 18, 2011 at 9:06 PM, Jose Ildefonso Camargo Tolosa
> wrote:
>>
>> Greetings,
>>
>> I have been thinking a lot about pgsql pe
Load testing of postgresql 8.4 for OLTP application
suitability showed that throughput of the
database significantly degraded over time from thousands of write
transactions per second to almost zero.
A typical postgres benchmarking gotcha is :
- you start with empty tables
- t
Hi,
We did a benchmark comparing a Key-Value-Pairs stored as EAV db schema
versus hstore.
The results are promising in favor of hstore but there are some
question which remain.
1. Obviously the '@>' has to be used in order to let use the GiST index.
Why is the '->' operator not supported by GiST
On 6/19/11 4:37 AM, Samuel Gendler wrote:
On Sat, Jun 18, 2011 at 9:06 PM, Jose Ildefonso Camargo Tolosa
mailto:ildefonso.cama...@gmail.com>> wrote:
Greetings,
I have been thinking a lot about pgsql performance when it is dealing
with tables with lots of rows on one table (several
On Sat, Jun 18, 2011 at 9:06 PM, Jose Ildefonso Camargo Tolosa <
ildefonso.cama...@gmail.com> wrote:
> Greetings,
>
> I have been thinking a lot about pgsql performance when it is dealing
> with tables with lots of rows on one table (several millions, maybe
> thousands of millions). Say, the Larg
