Hey all,
A month later, I have an updated plan for this with many more details.
I'd really appreciate it if folks would take a look and point out any
issues that you see. Here's my blog post explaining the current plan
with extensive details:
http://shawnwilsher.com/archives/169
Cheers,
Shawn
On Wed, Jul 2, 2008 at 4:58 AM, Dan <[EMAIL PROTECTED]> wrote:
> The idea here is to use a temp table as a cache for write operations
> on the
> real table, correct? To minimize the number of writes (and therefore
> fsync()
> operations) on the real table?
Yes, that is the overall goal.
> And the
On Jul 2, 2008, at 2:12 AM, Shawn Wilsher wrote:
> Hey all,
>
> I'm working with a partitioned table setup with a permanent table and
> a temp table with the same columns and indexes. Every X time we dump
> all the records in the temp table over to the permanent one. In order
> to make selectio
On Tue, Jul 1, 2008 at 4:05 PM, Igor Tandetnik <[EMAIL PROTECTED]> wrote:
> Will it? part is supposed to
> be false when the data is in fact currently in temp table. A WHERE
> clause that is always false will, naturally, produce no records.
Fair. I hadn't thought of doing something like that.
>>
Shawn Wilsher <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 1, 2008 at 3:37 PM, Igor Tandetnik
> <[EMAIL PROTECTED]> wrote:
>> They won't fail - they will successfully insert zero records. It's
>> perfectly valid to run INSERT ... SELECT and have the SELECT part
>> produce an empty resultset. It simply
On Tue, Jul 1, 2008 at 3:37 PM, Igor Tandetnik <[EMAIL PROTECTED]> wrote:
> They won't fail - they will successfully insert zero records. It's
> perfectly valid to run INSERT ... SELECT and have the SELECT part
> produce an empty resultset. It simply does nothing.
Sorry, I should have been more exp
Shawn Wilsher wrote:
> Hey all,
>
> I'm working with a partitioned table setup with a permanent table and
> a temp table with the same columns and indexes. Every X time we dump
> all the records in the temp table over to the permanent one. In order
> to make selection queries easier to manage, I
Shawn Wilsher <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 1, 2008 at 3:24 PM, Igor Tandetnik
> <[EMAIL PROTECTED]> wrote:
>> CREATE TRIGGER
>> BEGIN
>>insert into temp_table
>>select * from perm_table
>>where and
>> ;
>>
>>update temp_table set ...;
>> END;
> I had
On Tue, Jul 1, 2008 at 3:24 PM, Igor Tandetnik <[EMAIL PROTECTED]> wrote:
> CREATE TRIGGER
> BEGIN
>insert into temp_table
>select * from perm_table
>where and
> ;
>
>update temp_table set ...;
> END;
I had thought of this, but I'm pretty sure this will only work
Shawn Wilsher <[EMAIL PROTECTED]> wrote:
> I'm working with a partitioned table setup with a permanent table and
> a temp table with the same columns and indexes. Every X time we dump
> all the records in the temp table over to the permanent one. In order
> to make selection queries easier to man
Hey all,
I'm working with a partitioned table setup with a permanent table and
a temp table with the same columns and indexes. Every X time we dump
all the records in the temp table over to the permanent one. In order
to make selection queries easier to manage, I've gone and created a
view like
11 matches
Mail list logo
